On Mon, 22 Oct 2007 09:50:52 +1000, David Chinner <dgc@xxxxxxx> wrote:
On Fri, Oct 19, 2007 at 12:10:08PM +0200, Louis-David Mitterrand wrote:
On Fri, Oct 19, 2007 at 08:07:14AM +1000, David Chinner wrote:
> On Thu, Oct 18, 2007 at 03:11:16PM +0200, Louis-David Mitterrand
> > On Thu, Oct 18, 2007 at 07:24:39AM +1000, David Chinner wrote:
> > > On Wed, Oct 17, 2007 at 06:15:04PM +0200, Louis-David Mitterrand
> > > > Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I
> > > > remove that file:
> > > >
> > > > sylla:/# rm /lost+found/3912672557
> > > > rm: cannot remove `/lost+found/3912672557': Operation not
> > > >
> > > > sylla:/# ls -li /lost+found/3912672557
> > > > 3912672557 lrwxrwxrwx 1 root root 9 2006-04-09 19:10
/lost+found/3912672557 -> unix.7.gz
> > >
> > > Can you post the output of:
> > >
> > > # xfs_db -r -c "inode 3912672557" -c "p" <device>
> > Here:
> > core.magic = 0x494e
> > core.mode = 0120777
> > core.version = 1
> > core.format = 1 (local)
> > core.nlinkv1 = 1
> > core.immutable = 1
> You can't remove this link until you remove the immutable flag.
> # xfs_io -r -c "chattr -i" /lost+found/3912672557
sylla:~# xfs_io -r -c "chattr -i" /lost+found/3912672557
/lost+found/3912672557: No such file or directory
Strange. This implies that lookup can't find inode # 3912672557.
We know it is there...
How many other files in the directory? Can you get the inode number
for the lost+found directory and dump that with xfs_db (as per above)?
Also, what happens if you "touch /lost+found/unix.7.gz" and try again?
Being a symbolic link, xfs_io follows them rather than operates on
This will probably require xfs_db magic with the unmounted filesystem:
# xfs_db -x -c "inode 3912672557" -c "write core.immutable 0" <device>