Re: [2.6.12] XFS: Undeletable directory

[Jan De Luyck <lkml@kcore.org>]

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.