yes ext3 is old – but it works and you can undelete files – which can come in handy – because nobody is perfect – except god – and nobody should assume he/she is god.

it supports filesystems up to 4TB – which is still recent in 2017.

# identify disk
lsblk 
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sde      8:64   0 931.5G  0 disk 
└─sde1   8:65   0 931.5G  0 part /media/user/90701fda-8c95-42b7-818e-2a63c781104a

umount /dev/sde1; # unmount

tune2fs -L "NEWNAME" /dev/sde1; # label

mkfs.ext3 /dev/sde1; # format ext3 create filesystem ext3, this takes a while... 

mke2fs 1.42.12 (29-Aug-2014)
/dev/sde1 contains a ext3 file system labelled 'SUTFF'
        last mounted on Sun Dec  3 11:10:20 2017
Proceed anyway? (y,n) y
Creating filesystem with 244190208 4k blocks and 61054976 inodes
Filesystem UUID: 43c5d78f-70d0-45df-8cf7-ce17bf59cac5
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
        102400000, 214990848

Allocating group tables: done                            
Writing inode tables:  103/7453

fsck -y -v -f /dev/sde1; # check the filesystem just created

mkdir /mnt/sde1;
mount /dev/sde1 /mnt/sde1; # test mount

but this „feature“ makes me worry: Near-time Extinction due to Date-Stamp Limitation – This „Geek’s Millenium“ is expected to cause widespread disruption if not dealt with in a timely fashion. Ext3 stores dates as Unix time using four bytes in the file header. 32 bits does not give enough scope to continue processing files beyond January 18, 2038.[43]

Here’s an animation showing how the Year 2038 bug would reset the date – so i guess you should migrate to ext4 or BTRFS after 2030.

Source: Wikipedia
admin