Re: ext3 klaidos (2) [krx @ 2009-08-04 14:08:58]

Tema: Re: ext3 klaidos (2)
Autorius: krx
Data: 2009-08-04 14:08:58
Niu kad ne, čia iškart po remonto:

root@bgt-h:~# tune2fs -l  /dev/scsi/host1/bus0/target0/lun0/part2
tune2fs 1.41.8 (11-July-2009)
Filesystem volume name:   MMC
Last mounted on:          <not available>
Filesystem UUID:          25972283-2075-4aea-9823-cfeef2ed9382
Filesystem magic number:  0xEF53
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:              15261696
Block count:              61016878
Reserved block count:     0
Free blocks:              14825818
Free inodes:              15260589
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1009
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Filesystem created:       Thu Jan  8 21:38:43 2009
Last mount time:          Tue Aug  4 11:10:12 2009
Last write time:          Tue Aug  4 11:10:12 2009
Mount count:              1
Maximum mount count:      38
Last checked:             Tue Aug  4 10:47:15 2009
Check interval:           15552000 (6 months)
Next check after:         Sun Jan 31 10:47:15 2010
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      bfc9f75b-baff-4633-8988-5ad75f30ae4a
Journal backup:           inode blocks

-----------------

O čia, sukasi be remonto:


root@bgt-h:~# tune2fs -l  /dev/scsi/host0/bus0/target0/lun0/part2
tune2fs 1.41.8 (11-July-2009)
Filesystem volume name:   opt
Last mounted on:          <not available>
Filesystem UUID:          8757b816-2460-4a7e-bc4f-cd463a075bdc
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index 
filetype needs_recovery sparse_super
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              56224
Block count:              224908
Reserved block count:     6747
Free blocks:              159662
Free inodes:              51589
First block:              1
Block size:               1024
Fragment size:            1024
Reserved GDT blocks:      125
Blocks per group:         8192
Fragments per group:      8192
Inodes per group:         2008
Inode blocks per group:   251
Filesystem created:       Tue Oct 28 01:32:51 2008
Last mount time:          Thu Jan  1 00:00:14 1970
Last write time:          Thu Jan  1 00:00:14 1970
Mount count:              173
Maximum mount count:      38
Last checked:             Wed Dec 31 23:27:13 2008
Check interval:           15552000 (6 months)
Next check after:         Mon Jun 29 23:27:13 2009
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      54a79342-ed02-450c-9ca4-e14eb1d54fe1
Journal backup:           inode blocks


-----------

ir kas keista - maxcount viršytas jau senai senai, bet niekas boot'o metu 
netikrina. Ar vis dėl fsck reiktų leisti rankutėmis?



"rabarbaras" <rabarbaras@zebra.lt> wrote in message 
news:h58vv6$2ld$1@trimpas.omnitel.net...
> Manyciau kad reiketu paziureti tune2fs -l diskui kai sistema nuluzta, ir
> kai nusimontuoja be klaidu. Keista, nes su data=journal fsck turetu
> tikrinti tik be replay. Idomu,jei dd-wrt specifiskai pataiso maxcount.
>
> krx wrote:
>> Tai aš matau, kad galima patiuninti, bet kažkaip neturiu įrodymų, kad
>> ten kas nors vyksta, atsižvelgiant į tuos patikrinimo flag'us. Nes
>> kiekvieną kartą keikiasi, kad "maximal mount count reached".
>>
>> Nes šiaip fsck rankiniu būdu tikrina didesnę partciją (~220 GB) išties
>> netrumpai, ~keliolika min. (turbūt dėl USB sąsajos), todėl būtų
>> pastebėta arba natūraliai arba log'e.
>>
>> Tai vat klausimas, ar tas dd-wrt priverstinai suka tą fsck...