My laptop hdd partitions are encrypted and they are very big (hdd is 500GB).
So it is a bit annoying to run every 34 mounts the fschk …
I have looked into tune2fs and I have a doubt, and has this is a very delicate command, I would like to have some feedback from users who have experience with this issue.
I would like to extend the number of mounts until check disk is issued. So that the check is made either every 6 months (default) or, say at least 64 mounts (not the 34 default).
The command to do this should be something like this:
tune2fs -c 64 -i 6m /dev/mapper/home
(same for /dev/mapper/root)
Is this correct? Meaning: does this command, issued with the partitions unmounted, changes ONLY the boot check for 64 mounts or 6 Months?
Does this work for encrypted partitions?
I did not try to run tune2fs on encrypted file systems yet but for normal ext3(2) file systems your listed command works as expected. Issuing tune2fs for these values is safe as far as I know and from my own experience. It isn’t even necessary to unmount the device for this sort of tune2fs command (tune2fs will complain if the drive is mounted but the command requires an unmounted device). Maybe you want to read out the current values with dumpe2fs -h <device> first or check the new applied settings after issuing tune2fs.
The maximum mount count was 25 on my system by default and I also had to change it because it was checked too frequently
I will test this maybe during this weekend. I will assemble a new PC in order to test this thing.
Meantwhile I will let the system run like it is … just in case.
In principle (that is, theoretically) the tune2fs commands should work also on encrypted partitions.
I did made a tune2fs -h /dev/mapper/home
and the thing outputs:
tune2fs -l /dev/mapper/home
tune2fs 1.41.1 (01-Sep-2008)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: xxxxxxxxxxxxxxxxxxxxxx
Filesystem magic number: xxxxxxxxxxxxxxx
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 24903680
Block count: 99612783
Reserved block count: 4980639
Free blocks: 53673824
Free inodes: 24437734
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1000
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Filesystem created: Wed Dec 17 08:17:35 2008
Last mount time: Thu Feb 5 11:39:51 2009
Last write time: Thu Feb 5 11:39:51 2009
Mount count: 2
Maximum mount count: 32
Last checked: Wed Feb 4 09:50:44 2009
Check interval: 15552000 (6 months)
Next check after: Mon Aug 3 10:50:44 2009
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: xxxxxxxxxxxxxx
Journal backup: inode blocks
Nothing special about this …
Sometimes it is annoying … it always happens when we have to make a presentation …