public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [2.6.12] XFS: Undeletable directory
@ 2005-06-19 17:04 Jan De Luyck
       [not found] ` <Pine.LNX.4.63.0506191924430.7686@hobbybop>
  2005-06-20  7:04 ` Nathan Scott
  0 siblings, 2 replies; 7+ messages in thread
From: Jan De Luyck @ 2005-06-19 17:04 UTC (permalink / raw)
  To: linux-xfs, linux-kernel

Hello lists,

I've had some XFS troubles today, and after cleaning up with xfs_repair and so 
I'm stuck with one undeletable directory in /lost+found:

precious:/lost+found# ls -l
total 8
drwxrwxrwx  2 root root 8192 Jun 19  2005 4207214
precious:/lost+found# rm -r 4207214
rm: cannot remove directory `4207214': Directory not empty
precious:/lost+found# ls -l 4207214/
total 0
precious:/lost+found# 

So there's one dir 4207214 there, and i can rename it and whatever, just not 
remove it.

xfs_repair didn't solve the problem.

Any ideas?

Thanks,

Jan
-- 
    ***
  *******
 *********
 ****** Confucious say: "Is stuffy inside fortune cookie."
  *******
    ***

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [2.6.12] XFS: Undeletable directory
       [not found] ` <Pine.LNX.4.63.0506191924430.7686@hobbybop>
@ 2005-06-19 18:34   ` Jan De Luyck
  2005-06-19 23:02     ` Valdis.Kletnieks
  0 siblings, 1 reply; 7+ messages in thread
From: Jan De Luyck @ 2005-06-19 18:34 UTC (permalink / raw)
  To: Edwin Eefting; +Cc: linux-xfs, linux-kernel

On Sunday 19 June 2005 21:25, Edwin Eefting wrote:
> ls -la 4207214/ also shows nothing?
> perhaps there's something weirds thats hidden.
>

Nothing out of the ordinary:

devilkin@precious:/lost+found$ ls -la 4207214/
total 8
drwxrwxrwx  2 root root 8192 Jun 19  2005 .
drwxr-xr-x  3 root root   20 Jun 19  2005 ..
devilkin@precious:/lost+found$ 

Jan

-- 
  We are not anticipating any emergencies.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [2.6.12] XFS: Undeletable directory
  2005-06-19 18:34   ` Jan De Luyck
@ 2005-06-19 23:02     ` Valdis.Kletnieks
  2005-06-20 10:20       ` Jan De Luyck
  0 siblings, 1 reply; 7+ messages in thread
From: Valdis.Kletnieks @ 2005-06-19 23:02 UTC (permalink / raw)
  To: Jan De Luyck; +Cc: Edwin Eefting, linux-xfs, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

On Sun, 19 Jun 2005 20:34:18 +0200, Jan De Luyck said:
> On Sunday 19 June 2005 21:25, Edwin Eefting wrote:
> > ls -la 4207214/ also shows nothing?

> Nothing out of the ordinary:
> 
> devilkin@precious:/lost+found$ ls -la 4207214/
> total 8
> drwxrwxrwx  2 root root 8192 Jun 19  2005 .
> drwxr-xr-x  3 root root   20 Jun 19  2005 ..

Might want to do 'ls -lai' to get the inode numbers for . and .. and
then go sanity check them ('.' should have the same inode number as
lost+found/4207214, and '..' should have the same inode number as lost+found)

(and yes, I *know* fsck should whinge loudly if this is the case.  Wouldn't
be the first time I've seen an fsck fail to pick up on obvious corruption...)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [2.6.12] XFS: Undeletable directory
  2005-06-19 17:04 [2.6.12] XFS: Undeletable directory Jan De Luyck
       [not found] ` <Pine.LNX.4.63.0506191924430.7686@hobbybop>
@ 2005-06-20  7:04 ` Nathan Scott
  2005-06-20 10:25   ` Jan De Luyck
  1 sibling, 1 reply; 7+ messages in thread
From: Nathan Scott @ 2005-06-20  7:04 UTC (permalink / raw)
  To: Jan De Luyck; +Cc: linux-xfs, linux-kernel

On Sun, Jun 19, 2005 at 07:04:49PM +0200, Jan De Luyck wrote:
> Hello lists,
> 
> I've had some XFS troubles today, and after cleaning up with xfs_repair and so 
> I'm stuck with one undeletable directory in /lost+found:
> 
> precious:/lost+found# ls -l
> total 8
> drwxrwxrwx  2 root root 8192 Jun 19  2005 4207214
> precious:/lost+found# rm -r 4207214
> rm: cannot remove directory `4207214': Directory not empty
> precious:/lost+found# ls -l 4207214/
> total 0
> precious:/lost+found# 
> 
> So there's one dir 4207214 there, and i can rename it and whatever, just not 
> remove it.
> 
> xfs_repair didn't solve the problem.
> 
> Any ideas?

What does:  xfs_db -r -c 'inode 4207214' -c print /dev/XXX
report?

I have seen a similar thing once before, awhile back, where the
directory inode was "empty" (only . and ..) and hence should've
been in shortform, but other fields indicated the inode was in
extent form still.  Never got to the bottom of it... I'd guess
there's somehow a case where the kernel XFS code can miss this
transformation - not sure where/how though.

If it comes to it, you can always zero out individual inode fields
for that inode in xfs_db (with -x option to enable write mode) and
then xfs_repair should be able to get past it.

cheers.

-- 
Nathan

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [2.6.12] XFS: Undeletable directory
  2005-06-19 23:02     ` Valdis.Kletnieks
@ 2005-06-20 10:20       ` Jan De Luyck
  0 siblings, 0 replies; 7+ messages in thread
From: Jan De Luyck @ 2005-06-20 10:20 UTC (permalink / raw)
  To: linux-kernel; +Cc: Valdis.Kletnieks, Edwin Eefting, linux-xfs

On Monday 20 June 2005 01:02, Valdis.Kletnieks@vt.edu wrote:
> On Sun, 19 Jun 2005 20:34:18 +0200, Jan De Luyck said:
> > On Sunday 19 June 2005 21:25, Edwin Eefting wrote:
> > > ls -la 4207214/ also shows nothing?
> >
> > Nothing out of the ordinary:
> >
> > devilkin@precious:/lost+found$ ls -la 4207214/
> > total 8
> > drwxrwxrwx  2 root root 8192 Jun 19  2005 .
> > drwxr-xr-x  3 root root   20 Jun 19  2005 ..
>
> Might want to do 'ls -lai' to get the inode numbers for . and .. and
> then go sanity check them ('.' should have the same inode number as
> lost+found/4207214, and '..' should have the same inode number as
> lost+found)

The inode numbers are correct.

Jan

-- 
If the very old will remember, the very young will listen.
		-- Chief Dan George

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [2.6.12] XFS: Undeletable directory
  2005-06-20  7:04 ` Nathan Scott
@ 2005-06-20 10:25   ` Jan De Luyck
  2005-06-21  1:15     ` Federico Sevilla III
  0 siblings, 1 reply; 7+ messages in thread
From: Jan De Luyck @ 2005-06-20 10:25 UTC (permalink / raw)
  To: linux-kernel; +Cc: Nathan Scott, linux-xfs

On Monday 20 June 2005 09:04, Nathan Scott wrote:
> What does:  xfs_db -r -c 'inode 4207214' -c print /dev/XXX
> report?

precious:/lost+found/4207214# xfs_db -r -c 'inode 4207214' -c print /dev/hda6
core.magic = 0x494e
core.mode = 040777
core.version = 1
core.format = 2 (extents)
core.nlinkv1 = 2
core.uid = 0
core.gid = 0
core.flushiter = 275
core.atime.sec = Sun Jun 19 20:38:29 2005
core.atime.nsec = 790399992
core.mtime.sec = Sun Jun 19 20:37:45 2005
core.mtime.nsec = 608116720
core.ctime.sec = Sun Jun 19 20:38:16 2005
core.ctime.nsec = 795375536
core.size = 8192
core.nblocks = 2
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.gen = 0
next_unlinked = null
u.bmx[0-1] = [startoff,startblock,blockcount,extentflag] 0:[1,286547,1,0] 1:[8388608,286559,1,0]
precious:/lost+found/4207214# 

> If it comes to it, you can always zero out individual inode fields
> for that inode in xfs_db (with -x option to enable write mode) and
> then xfs_repair should be able to get past it.

Any idea how this should be set?

Thanks.
-- 
Hacker's Law:
	The belief that enhanced understanding will necessarily stir
	a nation to action is one of mankind's oldest illusions.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [2.6.12] XFS: Undeletable directory
  2005-06-20 10:25   ` Jan De Luyck
@ 2005-06-21  1:15     ` Federico Sevilla III
  0 siblings, 0 replies; 7+ messages in thread
From: Federico Sevilla III @ 2005-06-21  1:15 UTC (permalink / raw)
  To: linux-kernel, linux-xfs

On Mon, Jun 20, 2005 at 12:25:10PM +0200, Jan De Luyck wrote:
> On Monday 20 June 2005 09:04, Nathan Scott wrote:
> > If it comes to it, you can always zero out individual inode fields
> > for that inode in xfs_db (with -x option to enable write mode) and
> > then xfs_repair should be able to get past it.
> 
> Any idea how this should be set?

    # xfs_db -x -c 'inode XXX' -c 'write core.nextents 0' -c 'write core.size 0' /dev/hdXX

Cheers!

 --> Jijo

-- 
Federico Sevilla III : jijo.free.net.ph : When we speak of free software
GNU/Linux Specialist : GnuPG 0x93B746BE : we refer to freedom, not price.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2005-06-21  1:33 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-06-19 17:04 [2.6.12] XFS: Undeletable directory Jan De Luyck
     [not found] ` <Pine.LNX.4.63.0506191924430.7686@hobbybop>
2005-06-19 18:34   ` Jan De Luyck
2005-06-19 23:02     ` Valdis.Kletnieks
2005-06-20 10:20       ` Jan De Luyck
2005-06-20  7:04 ` Nathan Scott
2005-06-20 10:25   ` Jan De Luyck
2005-06-21  1:15     ` Federico Sevilla III

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox