public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Grozdan Nikolov (openSUSE Linux)" <microchip@telenet.be>
To: Justin Piszcz <jpiszcz@lucidpixels.com>
Cc: xfs@oss.sgi.com
Subject: Re: Cannot delete a directory on a XFS file system
Date: Sun, 13 Jan 2008 22:26:59 +0100	[thread overview]
Message-ID: <200801132226.59652.microchip@telenet.be> (raw)
In-Reply-To: <alpine.DEB.0.999999.0801131448070.17216@p34.internal.lan>

On Sunday 13 January 2008 20:49, you wrote:
> On Sun, 13 Jan 2008, Grozdan Nikolov (openSUSE Linux) wrote:
> > Hi,
> >
> > I have a small problem with XFS on a small 40 GB IDE disk that I use for
> > my music collection. The disk (/dev/hdb) has only one partition on it
> > formatted as XFS. On this partition, there is a directory that no matter
> > what I do, I cannot delete it. I tried everything, in Konqueror,
> > right-click on the directory and choose to delete it. As root on the
> > console
> > doing "rm -rf /media/data/DATA/MusicApps" ... but nothing works.
> >
> > When I try to "rm -rf" on this directory I get a message saying...
> >
> > rm: cannot remove directory `MusicApps/Loops/loops/Acid Loops/Bass':
> > Directory not empty
> >
> > But the "Bass" directory is completely empty, there's nothing in there.
> > Also when I unmount the file system and do a "xfs_check /dev/hdb1" I get
> > a message saying...
> >
> > link count mismatch for inode 184549517 (name ?), nlink 3, counted 2
> >
> > I did several times "xfs_repair /dev/hdb1" but I still get the same
> > result. xfs_check reports the same message and I still can't get rid of
> > this empty directory. I'm using kernel 2.6.24-rc7, but it's the same with
> > other kernels. I also did check the partition for bad block with the
> > "badblocks" program, but nothing came out, so the disk is just fine.
> >
> > Any ideas how I can delete this directory?
>
> The developers get in on Monday :P
>
> But some things they will ask:
>
> 1. run xfs_info /dev/hdb1

meta-data=/dev/hdb1              isize=256    agcount=16, agsize=610595 blks
         =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=9769520, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096
log      =internal               bsize=4096   blocks=4770, version=1
         =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=65536  blocks=0, rtextents=0

> 2. run (and capture the full output from the repair process)

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - clear lost+found (if it exists) ...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - ensuring existence of lost+found directory
        - traversing filesystem starting at / ...
        - traversal finished ...
        - traversing all unattached subtrees ...
        - traversals finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done

> 3. run ls -lR on the dir that has problems

MusicApps:
total 0
drwxr-xr-x 3 microchip users 18 2007-12-16 02:02 Loops

MusicApps/Loops:
total 0
drwxr-xr-x 3 microchip users 23 2007-12-16 02:02 loops

MusicApps/Loops/loops:
total 0
drwxr-xr-x 3 microchip users 17 2007-12-16 02:02 Acid Loops

MusicApps/Loops/loops/Acid Loops:
total 0
drwxr-xr-x 3 microchip users 6 2007-12-16 02:02 Bass

MusicApps/Loops/loops/Acid Loops/Bass:
total 0

> 4. run ls -li on the director(ies) that cannot be deleted for the inode #s

total 0
201326732 drwxr-xr-x 3 microchip users 18 2007-12-16 02:02 Loops

>
> If you give them this information in advance they'll have more info to
> help you.
>
> Justin.

  reply	other threads:[~2008-01-13 21:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-13 16:23 Cannot delete a directory on a XFS file system Grozdan Nikolov (openSUSE Linux)
2008-01-13 19:49 ` Justin Piszcz
2008-01-13 21:26   ` Grozdan Nikolov (openSUSE Linux) [this message]
2008-01-13 21:27   ` Eric Sandeen
2008-01-13 21:38     ` Grozdan Nikolov (openSUSE Linux)
2008-01-13 21:51       ` Eric Sandeen
2008-01-13 22:56         ` Grozdan Nikolov (openSUSE Linux)

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=200801132226.59652.microchip@telenet.be \
    --to=microchip@telenet.be \
    --cc=jpiszcz@lucidpixels.com \
    --cc=xfs@oss.sgi.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox