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

# format partition ext3 and label it at the same time
mkfs.ext3 /dev/sde1 -L "LABEL";

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

# just format partition ext3/create filesystem ext3
# this will take a while depending on the size of the disk
mkfs.ext3 /dev/sde1;

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
you might want to do regular filesystem checks:

tune2fs -C 2 -c 1 /dev/sda1; # check filesystem on every boot
tune2fs -c 10 -i 30 /dev/sda1; # check sda1 every 10 mounts or after 30 days

you can check that a filesystem check was performed with:

tune2fs -l /dev/sda1 | egrep -i "mount count|Check interval|Last|Next"

Last mounted on: /
Last mount time: Tue Jul 4 10:27:35 2017
Last write time: Tue Jul 4 10:06:15 2017
Mount count: 19
Maximum mount count: 10
Last checked: Tue Jun 27 11:05:21 2017
Check interval: 2592000 (1 month)
Next check after: Thu Jul 27 11:05:21 2017

if user uses raid

on CentOS8

tune2fs -c 5 -i 30 /dev/md0
tune2fs 1.45.6 (20-Mar-2020)
Setting maximal mount count to 5
Setting interval between checks to 2592000 seconds

tune2fs -c 5 -i 30 /dev/md2
tune2fs 1.45.6 (20-Mar-2020)
Setting maximal mount count to 5
Setting interval between checks to 2592000 seconds

if user uses encrypted harddisk and lvm2:

# path to device will look something like this
tune2fs -l /dev/hostname-vg/home | egrep -i "mount count|Check interval|Last|Next"
Last mounted on:          /home
Last mount time:          Wed May 27 08:21:22 2020
Last write time:          Wed May 27 08:21:22 2020
Mount count:              117
Maximum mount count:      -1
Last checked:             Tue Feb  4 11:37:28 2020
Check interval:           0 ()

# and as long as ext3 and ext4 are used
# this should work:
tune2fs -C 2 -c 1 /dev/hostname-vg/home
# also when using ssds filesystem check is pretty quick

liked this article?

  • only together we can create a truly free world
  • plz support dwaves to keep it up & running!
  • (yes the info on the internet is (mostly) free but beer is still not free (still have to work on that))
  • really really hate advertisement
  • contribute: whenever a solution was found, blog about it for others to find!
  • talk about, recommend & link to this blog and articles
  • thanks to all who contribute!
admin