I'm having some problems with /var on my machine. The machine itself is rather unstable and hangs every few days, but I don't think that is XFS-related. What does concern XFS is the data corruption
Seems that xfs_repair isn't very robust -- it doesn't even detect the problem on my disk that causes xfsdump to knock my rootfs offline. -l http://rhowe.sfarc.net/xfs_repair_var.txt.gz The output app
Russell - try renaming the lost+found/ dir before you re-run repair. Otherswise, it will unlink it and then re-find all those "lost" inodes. I don't think this is the root of the problem (the 990 err
There was an XFS problem in syncing when remounting read-only (which happens just before reboot), which was fixed earlier this year - it frequently affected /var because that is always very active du
Hm, I didn't realise all filesystems were remounted ro, I thought all but / were unmounted and then only / was remounted ro. Oh well you learn something new every day! See http://rhowe.sfarc.net/xfs_
they are. perhaps the readonly fix could also affect a plain umount as well. -- Ethan Benson http://www.alaska.net/~erbenson/ Attachment: pgpTFssdJ0jLP.pgp Description: PGP signature
No, you were right - I should have read your original mail more carefully. Thanks. Its as it seemed & repair is saying - the inode has an incorrect nblocks field for some reason. I will have to do so
Can you run the same (first) xfs_db command I sent to print out the inode, except change the 2222 to 6296608? I wonder if these two inodes are pointing at the same extents... No, a hard link would be
Taa. Hmmm, they look like distinct files, with completely disjoint extents (which is good). I'll still try to revisit this locally, but if you don't need to keep them, you should be able to blow thes
Hm, OK. I'll try that then. I also have another problem with /home (log corruption causing mount failure), but the emails I sent to the list about that seem to have been caught in limbo for no good r
I'm having some problems with /var on my machine. The machine itself is rather unstable and hangs every few days, but I don't think that is XFS-related. What does concern XFS is the data corruption
Seems that xfs_repair isn't very robust -- it doesn't even detect the problem on my disk that causes xfsdump to knock my rootfs offline. -l http://rhowe.sfarc.net/xfs_repair_var.txt.gz The output app
Russell - try renaming the lost+found/ dir before you re-run repair. Otherswise, it will unlink it and then re-find all those "lost" inodes. I don't think this is the root of the problem (the 990 err
There was an XFS problem in syncing when remounting read-only (which happens just before reboot), which was fixed earlier this year - it frequently affected /var because that is always very active du
Hm, I didn't realise all filesystems were remounted ro, I thought all but / were unmounted and then only / was remounted ro. Oh well you learn something new every day! See http://rhowe.sfarc.net/xfs_
they are. perhaps the readonly fix could also affect a plain umount as well. -- Ethan Benson http://www.alaska.net/~erbenson/ Attachment: pgpQn2yy0RFgJ.pgp Description: PGP signature
No, you were right - I should have read your original mail more carefully. Thanks. Its as it seemed & repair is saying - the inode has an incorrect nblocks field for some reason. I will have to do so
Can you run the same (first) xfs_db command I sent to print out the inode, except change the 2222 to 6296608? I wonder if these two inodes are pointing at the same extents... No, a hard link would be
Taa. Hmmm, they look like distinct files, with completely disjoint extents (which is good). I'll still try to revisit this locally, but if you don't need to keep them, you should be able to blow thes
Hm, OK. I'll try that then. I also have another problem with /home (log corruption causing mount failure), but the emails I sent to the list about that seem to have been caught in limbo for no good r