can't remove dir

can't remove dir

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

This is on debian unstable with 2.6.23-rc6.

Re: [UNSURE] can't remove dir

[Justin Piszcz]

On Fri, 14 Sep 2007, Louis-David Mitterrand wrote:

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

what does "ls -al 1879629858" say?

Re: [UNSURE] can't remove dir

[Louis-David Mitterrand]

On Fri, Sep 14, 2007 at 04:38:22AM -0400, Justin Piszcz wrote:
>
> On Fri, 14 Sep 2007, Louis-David Mitterrand wrote:
>>
>> 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.
>
> 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 ../

Re: [UNSURE] can't remove dir

[Justin Piszcz]

On Fri, 14 Sep 2007, Louis-David Mitterrand wrote:

> On Fri, Sep 14, 2007 at 04:38:22AM -0400, Justin Piszcz wrote:
>>
>> On Fri, 14 Sep 2007, Louis-David Mitterrand wrote:
>>>
>>> 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.
>>
>> 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 ../
>
>

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.

Re: [UNSURE] can't remove dir

[David Chinner]

On Fri, Sep 14, 2007 at 10:41:25AM +0200, Louis-David Mitterrand wrote:
> On Fri, Sep 14, 2007 at 04:38:22AM -0400, Justin Piszcz wrote:
> >
> > On Fri, 14 Sep 2007, Louis-David Mitterrand wrote:
> >>
> >> 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.
> >
> > 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:

> 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;
>>>>>>> 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.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: can't remove dir

[Louis-David Mitterrand]

On Fri, Sep 14, 2007 at 07:10:32PM +1000, David Chinner wrote:
> 
> 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

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

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

Re: can't remove dir

[David Chinner]

On Fri, Sep 14, 2007 at 11:27:21AM +0200, Louis-David Mitterrand wrote:
> On Fri, Sep 14, 2007 at 07:10:32PM +1000, David Chinner wrote:
> > 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.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: can't remove dir

[Barry Naujok]

On Fri, 14 Sep 2007 19:27:21 +1000, Louis-David Mitterrand  
<vindex+lists-xfs@apartia.org> wrote:

> On Fri, Sep 14, 2007 at 07:10:32PM +1000, David Chinner wrote:
>>
>> 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]
>

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.

Re: can't remove dir

[Eric Sandeen]

Louis-David Mitterrand wrote:
> 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.
> 
> 

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

Re: can't remove dir

[Eric Sandeen]

Eric Sandeen wrote:
> Louis-David Mitterrand wrote:
>> 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.
>>
>>
> 
> 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

Re: can't remove dir

[Louis-David Mitterrand]

On Fri, Sep 14, 2007 at 09:14:25AM -0500, Eric Sandeen wrote:
> Louis-David Mitterrand wrote:
> > 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.
> 
> 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

Re: can't remove dir

[Justin Piszcz]

On Wed, 17 Oct 2007, Louis-David Mitterrand wrote:

> On Fri, Sep 14, 2007 at 09:14:25AM -0500, Eric Sandeen wrote:
>> Louis-David Mitterrand wrote:
>>> 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.
>>
>> 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
>
>

lsattr -l /lost+found/3912672557

Shows?

Re: can't remove dir

[Louis-David Mitterrand]

On Wed, Oct 17, 2007 at 12:18:58PM -0400, Justin Piszcz wrote:
>>
>> 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?

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.

Re: can't remove dir

[David Chinner]

On Wed, Oct 17, 2007 at 06:15:04PM +0200, Louis-David Mitterrand wrote:
> 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.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: can't remove dir

[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 wrote:
> > 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>

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,

Re: can't remove dir

[David Chinner]

On Thu, Oct 18, 2007 at 03:11:16PM +0200, Louis-David Mitterrand wrote:
> 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 wrote:
> > > 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>
> 
> 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

as root should do the trick.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: can't remove dir

[Louis-David Mitterrand]

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 wrote:
> > 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 wrote:
> > > > 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>
> > 
> > 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

Tough cookie this one :)

Re: can't remove dir

[David Chinner]

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 wrote:
> > > 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 wrote:
> > > > > 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>
> > > 
> > > 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?

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: can't remove dir

[Barry Naujok]

On Mon, 22 Oct 2007 09:50:52 +1000, David Chinner <dgc@sgi.com> 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  
>> wrote:
>> > > 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  
>> wrote:
>> > > > > 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>
>> > >
>> > > 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?
>
> 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.

Re: can't remove dir

[David Chinner]

On Mon, Oct 22, 2007 at 10:42:25AM +1000, Barry Naujok wrote:
> On Mon, 22 Oct 2007 09:50:52 +1000, David Chinner <dgc@sgi.com> wrote:
> >On Fri, Oct 19, 2007 at 12:10:08PM +0200, Louis-David Mitterrand wrote:
> >>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
> 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.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: can't remove dir

[Louis-David Mitterrand]

On Mon, Oct 22, 2007 at 09:50:52AM +1000, David Chinner 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 wrote:
> > > > 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 wrote:
> > > > > > 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>
> > > > 
> > > > 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?

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

Re: can't remove dir

[Barry Naujok]

On Thu, 18 Oct 2007 02:15:04 +1000, Louis-David Mitterrand  
<vindex+lists-xfs@apartia.org> wrote:

> On Fri, Sep 14, 2007 at 09:14:25AM -0500, Eric Sandeen wrote:
>> Louis-David Mitterrand wrote:
>> > 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.
>>
>> 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

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.