Skip to contentSkip to conversation

can't remove dir

DISCUSSION Louis-David Mitterrand 5 participants 22 messages Sep 14, 2007 – Oct 22, 2007

lore
Share & tools
lore

Louis-David Mitterrand

author
#0 lore raw

Hello,

While cleaning up /lost+found a directory resisted removal:

	sylla:/lost+found# rm 1879629858 -rf
	rm: cannot remove directory `1879629858': Directory not empty

The directory _is_ empty and "-rf" should remove it anyway, so this looks like a fs error.

This is on debian unstable with 2.6.23-rc6.

#1 lore raw
Quoted 4 lines · Louis-David Mitterrand

Hello,

While cleaning up /lost+found a directory resisted removal:

Quoted 9 lines
	sylla:/lost+found# rm 1879629858 -rf
	rm: cannot remove directory `1879629858': Directory not empty

The directory _is_ empty and "-rf" should remove it anyway, so this looks like a fs error.

This is on debian unstable with 2.6.23-rc6.

what does "ls -al 1879629858" say?

author
#2 lore raw
Quoted 8 lines · Justin Piszcz
Quoted 6 lines · Louis-David Mitterrand

While cleaning up /lost+found a directory resisted removal:

	sylla:/lost+found# rm 1879629858 -rf
	rm: cannot remove directory `1879629858': Directory not empty
Quoted 7 lines
Quoted 4 lines

The directory _is_ empty and "-rf" should remove it anyway, so this looks like a fs error.

This is on debian unstable with 2.6.23-rc6.

what does "ls -al 1879629858" say?

I knew someone would ask, and this is slightly insulting ;-)

sylla:/lost+found# ls -al 1879629858
total 24
drwxr-xr-x 2 root root   8192 2007-09-14 09:25 ./
drwxr-xr-x 3 root root 299008 2007-09-14 10:05 ../
#3 lore raw
Quoted 17 lines · Louis-David Mitterrand
Quoted 8 lines · Justin Piszcz
Quoted 6 lines · Louis-David Mitterrand

While cleaning up /lost+found a directory resisted removal:

	sylla:/lost+found# rm 1879629858 -rf
	rm: cannot remove directory `1879629858': Directory not empty
Quoted 7 lines
Quoted 4 lines

The directory _is_ empty and "-rf" should remove it anyway, so this looks like a fs error.

This is on debian unstable with 2.6.23-rc6.

what does "ls -al 1879629858" say?

Quoted 8 lines

I knew someone would ask, and this is slightly insulting ;-)

sylla:/lost+found# ls -al 1879629858
total 24
drwxr-xr-x 2 root root   8192 2007-09-14 09:25 ./
drwxr-xr-x 3 root root 299008 2007-09-14 10:05 ../

What happens if you reboot to (e.g., knoppix)

and run: xfs_check /dev/that_partition?

and/or:

xfs_repair -n /dev/that_partition?

-n No modify mode. Specifies that xfs_repair should not modify the
filesystem but should only scan the filesystem and indicate what repairs would have been made.

This would be useful to figure out what went wrong.

Justin.

#4 lore raw
In reply to Louis-David Mitterrand
Quoted 12 lines · Louis-David Mitterrand
Quoted 11 lines · Justin Piszcz
Quoted 9 lines · Louis-David Mitterrand

While cleaning up /lost+found a directory resisted removal:

	sylla:/lost+found# rm 1879629858 -rf
	rm: cannot remove directory `1879629858': Directory not empty

The directory _is_ empty and "-rf" should remove it anyway, so this looks like a fs error.

Quoted 6 lines
Quoted 4 lines
Quoted 1 line

This is on debian unstable with 2.6.23-rc6.

what does "ls -al 1879629858" say?

I knew someone would ask, and this is slightly insulting ;-)

Well, feel insulted if you want, but it was *exactly* the right question to ask. :/

Looking at the link count of the directory that can't be removed:

Quoted 3 lines
sylla:/lost+found# ls -al 1879629858
total 24
drwxr-xr-x 2 root root   8192 2007-09-14 09:25 ./

Which is correct for an empty directory. So this code in xfs_rmdir:

        ASSERT(cdp->i_d.di_nlink >= 2);
        if (cdp->i_d.di_nlink != 2) {
                error = XFS_ERROR(ENOTEMPTY);
                goto error_return;
        }

is not where the error is coming from.

But, the size indicates that the dirctory is not in shortform state. An empty directory should look like:

# mkdir empty
# ls -la empty
total 0
drwxrwxr-x 2 root root  6 Sep 14 18:58 ./
                       ^^
drwxrwxr-x 4 root root 28 Sep 14 18:58 ../
#

So that means the error came from:

        if (!xfs_dir_isempty(cdp)) {
                error = XFS_ERROR(ENOTEMPTY);
                goto error_return;
        }

xfs_dir_isempty(
xfs_inode_t *dp)

{
        xfs_dir2_sf_t   *sfp;

        ASSERT((dp->i_d.di_mode & S_IFMT) == S_IFDIR);
        if (dp->i_d.di_size == 0)       /* might happen during shutdown. */
                return 1;
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

if (dp->i_d.di_size > XFS_IFORK_DSIZE(dp))

        return 0;
        sfp = (xfs_dir2_sf_t *)dp->i_df.if_u1.if_data;
        return !sfp->hdr.count;
}

So, this wasn't a stupid question at all. It indicates that the source of the problem is a directory that did not get converted back to short form as the entries were removed and greatly narrows down teh possible causes of the problem.

Can you tell us the output of 'xfs_info <mntpt>'?

Also, get the inode number of the bad directory (ls -i) and then run:

# xfs_db -r -c "inode <inode_num>" -c "p" <device of fs>

So we can see what the state of the inode is?

BTW, what problem led you to running xfs_repair in the first place (i.e. what led to lost+found getting populated)?

Cheers,

Dave.

Signature · 3 lines
Dave Chinner
Principal Engineer
SGI Australian Software Group
author
#5 lore raw
Quoted 2 lines · David Chinner

Can you tell us the output of 'xfs_info <mntpt>'?

sylla:~# xfs_info /
meta-data=/dev/root              isize=256    agcount=41, agsize=15252656 blks
         =                       sectsz=4096  attr=1
data     =                       bsize=4096   blocks=610178720, imaxpct=25
         =                       sunit=16     swidth=80 blks, unwritten=1
naming   =version 2              bsize=4096  
log      =internal               bsize=4096   blocks=32768, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=0
realtime =none                   extsz=327680 blocks=0, rtextents=0
Quoted 4 lines

Also, get the inode number of the bad directory (ls -i) and then run:

# xfs_db -r -c "inode <inode_num>" -c "p" <device of fs>
sylla:/lost+found# xfs_db -r -c "inode 1879629858" -c "p" /dev/md1
core.magic = 0x494e
core.mode = 040755
core.version = 1
core.format = 2 (extents)
core.nlinkv1 = 2
core.uid = 0
core.gid = 0
core.flushiter = 9
core.atime.sec = Tue Aug  1 20:49:16 2006
core.atime.nsec = 000000000
core.mtime.sec = Fri Sep 14 09:25:29 2007
core.mtime.nsec = 589593557
core.ctime.sec = Fri Sep 14 09:25:29 2007
core.ctime.nsec = 589593557
core.size = 8192
core.nblocks = 3
core.extsize = 0
core.nextents = 2
core.naextents = 0
core.forkoff = 0
core.aformat = 2 (extents)
core.dmevmask = 0
core.dmstate = 0
core.newrtbm = 0
core.prealloc = 0
core.realtime = 0
core.immutable = 0
core.append = 0
core.sync = 0
core.noatime = 0
core.nodump = 0
core.rtinherit = 0
core.projinherit = 0
core.nosymlinks = 0
core.extsz = 0
core.extszinherit = 0
core.nodefrag = 0
core.gen = 0
next_unlinked = null
u.bmx[0-1] = [startoff,startblock,blockcount,extentflag] 0:[0,117476868,2,0] 1:[8388608,125865476,1,0]
Quoted 4 lines

So we can see what the state of the inode is?

BTW, what problem led you to running xfs_repair in the first place (i.e. what led to lost+found getting populated)?

The infamous 2.6.17.1 corruption.

Thanks,

#6 lore raw
Quoted 5 lines · Louis-David Mitterrand
Quoted 2 lines · David Chinner

BTW, what problem led you to running xfs_repair in the first place (i.e. what led to lost+found getting populated)?

The infamous 2.6.17.1 corruption.

Well, that explains it ;)

http://oss.sgi.com/projects/xfs/faq.html#dir2

"To add insult to injury, xfs_repair(8) is currently not correcting these directories on detection of this corrupt state either. This xfs_repair issue is actively being worked on, and a fixed version will be available shortly.

Update: a fixed xfs_repair is now available; version 2.8.10 or later of the xfsprogs package contains the fixed version."

What version of xfs_repair are you using? (xfs_repair -V)

Cheers,

Dave.

Signature · 3 lines
Dave Chinner
Principal Engineer
SGI Australian Software Group
#7 lore raw
In reply to Louis-David Mitterrand
Quoted 40 lines · Louis-David Mitterrand
Quoted 5 lines · David Chinner

Also, get the inode number of the bad directory (ls -i) and then run:

# xfs_db -r -c "inode <inode_num>" -c "p" <device of fs>
sylla:/lost+found# xfs_db -r -c "inode 1879629858" -c "p" /dev/md1
core.magic = 0x494e
core.mode = 040755
core.version = 1
core.format = 2 (extents)
core.nlinkv1 = 2
core.uid = 0
core.gid = 0
core.flushiter = 9
core.atime.sec = Tue Aug  1 20:49:16 2006
core.atime.nsec = 000000000
core.mtime.sec = Fri Sep 14 09:25:29 2007
core.mtime.nsec = 589593557
core.ctime.sec = Fri Sep 14 09:25:29 2007
core.ctime.nsec = 589593557
core.size = 8192
core.nblocks = 3
core.extsize = 0
core.nextents = 2
core.naextents = 0
core.forkoff = 0
core.aformat = 2 (extents)
core.dmevmask = 0
core.dmstate = 0
core.newrtbm = 0
core.prealloc = 0
core.realtime = 0
core.immutable = 0
core.append = 0
core.sync = 0
core.noatime = 0
core.nodump = 0
core.rtinherit = 0
Quoted 9 lines
core.projinherit = 0
core.nosymlinks = 0
core.extsz = 0
core.extszinherit = 0
core.nodefrag = 0
core.gen = 0
next_unlinked = null
u.bmx[0-1] = [startoff,startblock,blockcount,extentflag] 0:[0,117476868,2,0] 1:[8388608,125865476,1,0]

If you still have the bad directory, can you run these as well?

# xfs_db -r -c "inode 1879629858" -c "dblock 0" -c "p" /dev/md1
# xfs_db -r -c "inode 1879629858" -c "dblock 1" -c "p" /dev/md1
# xfs_db -r -c "inode 1879629858" -c "dblock 8388608" -c "p" /dev/md1

Thanks,
Barry.

#8 lore raw
In reply to Louis-David Mitterrand
Quoted 4 lines · Louis-David Mitterrand

Hello,

While cleaning up /lost+found a directory resisted removal:

Quoted 9 lines
	sylla:/lost+found# rm 1879629858 -rf
	rm: cannot remove directory `1879629858': Directory not empty

The directory _is_ empty and "-rf" should remove it anyway, so this looks like a fs error.

This is on debian unstable with 2.6.23-rc6.

Any errors in the system logs? I'd try most recent xfs_repair next. If that doesn't fix it, make an xfs_metadump for Barry to look at. :) Make a backup first if you're paranoid.

-Eric

#9 lore raw
Quoted 11 lines · Eric Sandeen
Quoted 10 lines · Louis-David Mitterrand

Hello,

While cleaning up /lost+found a directory resisted removal:

	sylla:/lost+found# rm 1879629858 -rf
	rm: cannot remove directory `1879629858': Directory not empty

The directory _is_ empty and "-rf" should remove it anyway, so this looks like a fs error.

Quoted 7 lines
Quoted 3 lines

This is on debian unstable with 2.6.23-rc6.

Any errors in the system logs? I'd try most recent xfs_repair next. If that doesn't fix it, make an xfs_metadump for Barry to look at. :) Make a backup first if you're paranoid.

Some day I'll learn to read all of a thread before replying... ignore me. Looks like dgc has things well under control. :)

-Eric

author
#10 lore raw
In reply to Eric Sandeen
Quoted 8 lines · Eric Sandeen
Quoted 7 lines · Louis-David Mitterrand

Hello,

While cleaning up /lost+found a directory resisted removal:

	sylla:/lost+found# rm 1879629858 -rf
	rm: cannot remove directory `1879629858': Directory not empty
Quoted 8 lines
Quoted 4 lines

The directory _is_ empty and "-rf" should remove it anyway, so this looks like a fs error.

This is on debian unstable with 2.6.23-rc6.

Any errors in the system logs? I'd try most recent xfs_repair next. If that doesn't fix it, make an xfs_metadump for Barry to look at. :) Make a backup first if you're paranoid.

Hi again,

Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I can't remove that file:

sylla:/# rm /lost+found/3912672557
rm: cannot remove `/lost+found/3912672557': Operation not permitted
sylla:/# ls -li /lost+found/3912672557                                 
3912672557 lrwxrwxrwx 1 root root 9 2006-04-09 19:10 /lost+found/3912672557 -> unix.7.gz
#11 lore raw
Quoted 20 lines · Louis-David Mitterrand
Quoted 8 lines · Eric Sandeen
Quoted 7 lines · Louis-David Mitterrand

Hello,

While cleaning up /lost+found a directory resisted removal:

	sylla:/lost+found# rm 1879629858 -rf
	rm: cannot remove directory `1879629858': Directory not empty
Quoted 8 lines
Quoted 4 lines

The directory _is_ empty and "-rf" should remove it anyway, so this looks like a fs error.

This is on debian unstable with 2.6.23-rc6.

Any errors in the system logs? I'd try most recent xfs_repair next. If that doesn't fix it, make an xfs_metadump for Barry to look at. :) Make a backup first if you're paranoid.

Hi again,

Quoted 10 lines

Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I can't remove that file:

sylla:/# rm /lost+found/3912672557
rm: cannot remove `/lost+found/3912672557': Operation not permitted
sylla:/# ls -li /lost+found/3912672557
3912672557 lrwxrwxrwx 1 root root 9 2006-04-09 19:10 /lost+found/3912672557 -> unix.7.gz

lsattr -l /lost+found/3912672557

Shows?

author
#12 lore raw
Quoted 7 lines · Justin Piszcz
Quoted 7 lines

Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I can't remove that file:

sylla:/# rm /lost+found/3912672557
rm: cannot remove `/lost+found/3912672557': Operation not permitted
Quoted 8 lines
Quoted 4 lines
sylla:/# ls -li /lost+found/3912672557
3912672557 lrwxrwxrwx 1 root root 9 2006-04-09 19:10 
/lost+found/3912672557 -> unix.7.gz

lsattr -l /lost+found/3912672557

Shows?

sylla:~# lsattr -l /lost+found/3912672557
lsattr: No such file or directory While reading flags on /lost+found/3912672557

The file is a dangling link.

#13 lore raw
In reply to Louis-David Mitterrand
Quoted 8 lines · Louis-David Mitterrand

Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I can't remove that file:

sylla:/# rm /lost+found/3912672557
rm: cannot remove `/lost+found/3912672557': Operation not permitted
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>

Cheers,

Dave.

Signature · 3 lines
Dave Chinner
Principal Engineer
SGI Australian Software Group
author
#14 lore raw
Quoted 7 lines · David Chinner
Quoted 6 lines · Louis-David Mitterrand

Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I can't remove that file:

sylla:/# rm /lost+found/3912672557
rm: cannot remove `/lost+found/3912672557': Operation not permitted
Quoted 6 lines
Quoted 2 lines
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.uid = 0
core.gid = 0
core.flushiter = 1
core.atime.sec = Sun Apr 9 19:10:38 2006
core.atime.nsec = 316368304
core.mtime.sec = Sun Apr 9 19:10:38 2006
core.mtime.nsec = 316368304
core.ctime.sec = Sun Apr 9 19:10:38 2006
core.ctime.nsec = 317368152
core.size = 9
core.nblocks = 0
core.extsize = 0
core.nextents = 0
core.naextents = 0
core.forkoff = 0
core.aformat = 2 (extents)
core.dmevmask = 0x4d291522
core.dmstate = 21036
core.newrtbm = 0
core.prealloc = 0
core.realtime = 0
core.immutable = 1
core.append = 1
core.sync = 0
core.noatime = 1
core.nodump = 0
core.rtinherit = 1
core.projinherit = 0
core.nosymlinks = 0
core.extsz = 0
core.extszinherit = 0
core.nodefrag = 1
core.gen = 0
next_unlinked = null
u.symlink = "unix.7.gz"

Thanks,

#15 lore raw
Quoted 22 lines · Louis-David Mitterrand
Quoted 7 lines · David Chinner
Quoted 6 lines · Louis-David Mitterrand

Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I can't remove that file:

sylla:/# rm /lost+found/3912672557
rm: cannot remove `/lost+found/3912672557': Operation not permitted
Quoted 6 lines
Quoted 2 lines
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

.....

Quoted 1 line

core.immutable = 1

^^^^^^^^^^^^^^^^^^

You can't remove this link until you remove the immutable flag.

# xfs_io -r -c "chattr -i" /lost+found/3912672557

as root should do the trick.

Cheers,

Dave.

Signature · 3 lines
Dave Chinner
Principal Engineer
SGI Australian Software Group
author
#16 lore raw
Quoted 23 lines · David Chinner
Quoted 15 lines · Louis-David Mitterrand
Quoted 7 lines · David Chinner
Quoted 6 lines · Louis-David Mitterrand

Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I can't remove that file:

sylla:/# rm /lost+found/3912672557
rm: cannot remove `/lost+found/3912672557': Operation not permitted
Quoted 6 lines
Quoted 2 lines
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>
Quoted 7 lines

Here:

core.magic = 0x494e
core.mode = 0120777
core.version = 1
core.format = 1 (local)
core.nlinkv1 = 1

Quoted 7 lines

.....

Quoted 1 line

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

Tough cookie this one :)

#17 lore raw
Quoted 26 lines · Louis-David Mitterrand
Quoted 25 lines · David Chinner
Quoted 22 lines · Louis-David Mitterrand
Quoted 7 lines · David Chinner
Quoted 6 lines · Louis-David Mitterrand

Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I can't remove that file:

sylla:/# rm /lost+found/3912672557
rm: cannot remove `/lost+found/3912672557': Operation not permitted
Quoted 6 lines
Quoted 2 lines
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

.....

Quoted 1 line

core.immutable = 1

Quoted 8 lines
Quoted 5 lines

^^^^^^^^^^^^^^^^^^

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?

Cheers,

Dave.

Signature · 3 lines
Dave Chinner
Principal Engineer
SGI Australian Software Group
#18 lore raw
Quoted 44 lines · David Chinner
Quoted 31 lines · Louis-David Mitterrand
Quoted 1 line · David Chinner

On Thu, Oct 18, 2007 at 03:11:16PM +0200, Louis-David Mitterrand

Quoted 2 lines · wrote:
Quoted 2 lines · David Chinner
Quoted 1 line

On Wed, Oct 17, 2007 at 06:15:04PM +0200, Louis-David Mitterrand

Quoted 1 line · wrote:
Quoted 1 line
Quoted 1 line
Quoted 1 line

Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I

can't

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

remove that file:

sylla:/# rm /lost+found/3912672557
rm: cannot remove `/lost+found/3912672557': Operation not

permitted

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
sylla:/# ls -li /lost+found/3912672557
3912672557 lrwxrwxrwx 1 root root 9 2006-04-09 19:10

/lost+found/3912672557 -> unix.7.gz

Quoted 14 lines
Quoted 12 lines
Quoted 4 lines

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

.....

Quoted 1 line

core.immutable = 1

Quoted 8 lines
Quoted 5 lines

^^^^^^^^^^^^^^^^^^

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...

Quoted 8 lines

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?

Cheers,

Dave.

Being a symbolic link, xfs_io follows them rather than operates on them directory.

This will probably require xfs_db magic with the unmounted filesystem:

# xfs_db -x -c "inode 3912672557" -c "write core.immutable 0" <device>

Barry.

#19 lore raw
Quoted 8 lines · Barry Naujok
Quoted 7 lines · David Chinner
Quoted 2 lines · Louis-David Mitterrand
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...

Quoted 7 lines
Quoted 4 lines

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 them directory.

Actually, I tested that before posting. If the symlink is dangling, then the symlink gets the attributes attached to it:

# ls -l /mnt/scratch/
total 0
lrwxrwxrwx 1 root root 22 Oct 22 11:09 foo -> /mnt/scratch/unix.7.gz
# ls -l /mnt/scratch/unix.7.gz
/bin/ls: /mnt/scratch/unix.7.gz: No such file or directory
# xfs_io -f -r -c "lsattr" /mnt/scratch/foo
-------------- /mnt/scratch/foo
# xfs_io -f -c "chattr +i" /mnt/scratch/foo
# xfs_io -f -r -c "lsattr" /mnt/scratch/foo
--i----------- /mnt/scratch/foo
# umount /mnt/scratch
# mount !$
mount /mnt/scratch
# xfs_io -f -r -c "lsattr" /mnt/scratch/foo
--i----------- /mnt/scratch/foo
# xfs_io -f -c "chattr -i" /mnt/scratch/foo -r
# xfs_io -f -r -c "lsattr" /mnt/scratch/foo
-------------- /mnt/scratch/foo
#

Cheers,

Dave.

Signature · 3 lines
Dave Chinner
Principal Engineer
SGI Australian Software Group
author
#20 lore raw
In reply to David Chinner
Quoted 36 lines · David Chinner
Quoted 26 lines · Louis-David Mitterrand
Quoted 25 lines · David Chinner
Quoted 22 lines · Louis-David Mitterrand
Quoted 7 lines · David Chinner
Quoted 6 lines · Louis-David Mitterrand

Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I can't remove that file:

sylla:/# rm /lost+found/3912672557
rm: cannot remove `/lost+found/3912672557': Operation not permitted
Quoted 6 lines
Quoted 2 lines
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

.....

Quoted 1 line

core.immutable = 1

Quoted 8 lines
Quoted 5 lines

^^^^^^^^^^^^^^^^^^

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
Quoted 7 lines

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?

sylla:/lost+found# touch /lost+found/unix.7.gz   
sylla:/lost+found# l
total 0
lrwxrwxrwx 1 root root 9 2006-04-09 19:10 3912672557 -> unix.7.gz
-rw-r--r-- 1 root root 0 2007-10-22 09:02 unix.7.gz
sylla:/lost+found# xfs_io -r -c "chattr -i" /lost+found/3912672557
sylla:/lost+found# rm 3912672557
rm: remove symbolic link `3912672557'? y
rm: cannot remove `3912672557': Operation not permitted
#21 lore raw
In reply to Louis-David Mitterrand
Quoted 20 lines · Louis-David Mitterrand
Quoted 8 lines · Eric Sandeen
Quoted 7 lines · Louis-David Mitterrand

Hello,

While cleaning up /lost+found a directory resisted removal:

	sylla:/lost+found# rm 1879629858 -rf
	rm: cannot remove directory `1879629858': Directory not empty
Quoted 8 lines
Quoted 4 lines

The directory _is_ empty and "-rf" should remove it anyway, so this looks like a fs error.

This is on debian unstable with 2.6.23-rc6.

Any errors in the system logs? I'd try most recent xfs_repair next. If that doesn't fix it, make an xfs_metadump for Barry to look at. :) Make a backup first if you're paranoid.

Hi again,

Quoted 8 lines

Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I can't remove that file:

sylla:/# rm /lost+found/3912672557
rm: cannot remove `/lost+found/3912672557': Operation not permitted
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 apply the patch in
http://oss.sgi.com/archives/xfs/2007-09/msg00222.html
and run the patched repair on your filesytem?

Barry.