On Thu, 2002-01-17 at 13:08, Wessel Dankers wrote:
> I think tripped over a nice, juicy bug here. I used ftruncate64() to create
> a sparse file of 2^63 bytes. Then I run mkfs.xfs on it (without any options).
> The filesystem on which the large file resides goes belly-up and refuses
> to perform any operation at all, returning EIO on even an ls.
> I can umount it (although running a sync hangs for a while) but xfs_check
> fails because the superblock is overwritten (!). After xfs_repair, mount,
> xfs_repair -L, everything is OK again and I don't seem to have lost any
> files (I didn't look very closely though, it was just my /tmp). This is
> in dmesg:
> xfs_force_shutdown(ide0(3,6),0x8) called from line 1020 of file xfs_trans.c.
> Return address = 0xc01bdfc7
> Corruption of in-memory data detected. Shutting down filesystem: ide0(3,6)
> Please umount the filesystem, and rectify the problem(s)
> I hope it's not a known bug, I'd hate to waste your time.
Someone else just pointed out that forced shutdown is overwriting the
super block - which is not good. There appear to be a bunch of dirty
buffers with a zero disk address in them left behind. It is being
> Wessel Dankers <wsl@xxxxxxxxxxxx>
> Telecommunications is downshifting.
Steve Lord voice: +1-651-683-3511
Principal Engineer, Filesystem Software email: lord@xxxxxxx