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.
next prev parent 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 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.