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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]