On Tue, 2002-01-22 at 08:56, Daniel Just wrote:
> Hello Austin,
>
> thanks for your reply.
>
> * Austin Gonyou <austin@xxxxxxxxxxxxxxx> [21-01-02 20:57]:
>
> > It sounds like a possible HW issue. Could also be your partition setup
> > too. You don't have overlapping partitions do you? Just curious.
>
> No.
>
> > In regards to 2.4.17, I'm running it on my 1550 at my desk, but I have
> > problems with that kernel corrupting files from time to time. I'm not
>
> I haven't experienced anything like that before, I'm using xfs since
> 2.4.9 without any trouble.
>
> I didn't post about my hardware-setup as suggested in the FAQ: Intel
> LX Chipset, WDC WD300BB-00AUA1 ATA DISK drive
>
> I repeated that test I did yesterday once again and that is what
> xfs_check told me afterwards: (the first error-entries in
> /var/log/messages occured when the file had approximately 1GB)
> (shortened)
>
> bad agf magic # 0 in ag 0
> bad agf version # 0 in ag 0
> block 0/0 expected type unknown got sb
> bad agi magic # 0 in ag 0
> bad agi version # 0 in ag 0
> bad magic # 0x58465342 in btbno block 0/0
> bad magic # 0x58465342 in btcnt block 0/0
> bad magic # 0x58465342 in inobt block 0/0
> agi unlinked bucket 0 is 0 in ag 0 (inode=0)
> agi unlinked bucket 1 is 0 in ag 0 (inode=0)
> [...]
> agi unlinked bucket 62 is 0 in ag 0 (inode=0)
> agi unlinked bucket 63 is 0 in ag 0 (inode=0)
> block 0/6491 expected type unknown got missing
> block 0/6492 expected type unknown got missing
> [...]
> block 0/814 expected type unknown got missing
> block 0/815 expected type unknown got missing
>
> Doing 'cat file-with-700MB >> otherfile' repeatedly let me produce a
> file with 9GB without any problems on this partition.
>
> [time passes]
>
> Finally, I grabbed a kernel from cvs today, and all I can say is that
> all works fine right now. I've just dd'ed a file with 3GB without any
> problem.
A change went in late last week which was to fix forced shutdown
corrupting the filesystem. However, what it really did was correctly
discard a delayed allocate buffer which we had failed to allocate
space for on disk for some reason. End result prior to this was
a buffer with filedata in it landing on block zero of the partition -
which is the superblock.
Since you were writing zeros this ties in with what you saw, the
data being complained about by xfs_repair is within the first 4K of
the partition.
Steve
--
Steve Lord voice: +1-651-683-3511
Principal Engineer, Filesystem Software email: lord@xxxxxxx
|