All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Scott <nathans@sgi.com>
To: Jan De Luyck <lkml@kcore.org>
Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org
Subject: Re: [2.6.12] XFS: Undeletable directory
Date: Mon, 20 Jun 2005 17:04:59 +1000	[thread overview]
Message-ID: <20050620070459.GB1549@frodo> (raw)
In-Reply-To: <200506191904.49639.lkml@kcore.org>

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

  parent reply	other threads:[~2005-06-20  7:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2005-06-20 10:25   ` Jan De Luyck
2005-06-21  1:15     ` Federico Sevilla III

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050620070459.GB1549@frodo \
    --to=nathans@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@oss.sgi.com \
    --cc=lkml@kcore.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.