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 the 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.
I would like to extend the check mount time. So that the check is made
either every 6 months (default) or, say at least 64 mounts.
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
un-mounted, changes ONLY the boot check for 64 mounts or 6 Months?
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 …
Monex;1938966 Wrote:
> Hi,
>
> 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
>
> Hope this helps
Sometimes it is annoying … it always happens when we have to make
a presentation …
… it always happens when we have to make