Codice: Seleziona tutto
if [ ! -r /etc/fastboot ]; then
echo "Checking root filesystem:"
Sì, almeno per ext2 è così.PS: non ti so dire però a cosa sia dovuto il 25. Forse è una 'possibilità' impostabile per il tipo di filesystem,
Codice: Seleziona tutto
root@darkenergy:/home/g# dumpe2fs -h /dev/hda1
dumpe2fs 1.40.2 (12-Jul-2007)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 96bfa069-8075-4691-badf-9ea0b2c78eb9
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: filetype sparse_super
Default mount options: (none)
Filesystem state: not clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 3908128
Block count: 7811598
Reserved block count: 0
Free blocks: 3984888
Free inodes: 3588428
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16352
Inode blocks per group: 511
Filesystem created: Sat Feb 10 15:16:43 2007
Last mount time: Tue Aug 7 16:25:49 2007
Last write time: Tue Aug 7 17:46:39 2007
Mount count: 26
Maximum mount count: 37
Last checked: Fri Aug 3 14:29:44 2007
Check interval: 15552000 (6 months)
Next check after: Wed Jan 30 13:29:44 2008
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Default directory hash: tea
Directory Hash Seed: e20861e6-4a72-4cbf-8ef5-65781d453527
Ti sconsiglio di impostare dei controlli troppo rari, in passato l'ho fatto e alla fine ho avuto dei problemi...-c max-mount-counts
Adjust the number of mounts after which the filesystem will be
checked by e2fsck(8). If max-mount-counts is 0 or -1, the num-
ber of times the filesystem is mounted will be disregarded by
e2fsck(8) and the kernel.
Staggering the mount-counts at which filesystems are forcibly
checked will avoid all filesystems being checked at one time
when using journaled filesystems.
You should strongly consider the consequences of disabling
mount-count-dependent checking entirely. Bad disk drives,
cables, memory, and kernel bugs could all corrupt a filesystem
without marking the filesystem dirty or in error. If you are
using journaling on your filesystem, your filesystem will never
be marked dirty, so it will not normally be checked. A filesys-
tem error detected by the kernel will still force an fsck on the
next reboot, but it may already be too late to prevent data loss
at that point.
See also the -i option for time-dependent checking.