xfs
[Top] [All Lists]

Re: file preallocation without unwritten flag being set

To: p v <pvlogin@xxxxxxxxx>
Subject: Re: file preallocation without unwritten flag being set
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Wed, 13 May 2009 16:48:39 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <705795.15734.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <283244.29270.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <4A0A0E76.6000701@xxxxxxxxxxx> <618437.93111.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <4A0A55E0.4010202@xxxxxxxxxxx> <705795.15734.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
User-agent: Thunderbird 2.0.0.21 (X11/20090320)
p v wrote:
> doesn't seem to work - I tried to clear the extflg in the versionnum
> of the superblock (in every copy of it as well) but it doesn't work.
> The flag is still set on all extents.
> 
> xfs_db> version versionnum [0xb4a4+0x8] =
> V4,NLINK,ALIGN,DIRV2,LOGV2,EXTFLG,MOREBITS,ATTR2 xfs_db> version
> 0xa4a4 0x8 versionnum [0xa4a4+0x8] =
> V4,NLINK,ALIGN,DIRV2,LOGV2,MOREBITS,ATTR2
> 
> typeset -i agcount=$(xfs_db -c "sb" -c "print" /dev/sda | grep
> agcount) typeset -i i=0 while [[ $i != $agcount ]] do xfs_db -x -c
> "sb $i" -c "write versionnum 0xa4a4" /dev/sda i=i+1 done
> 
> And once I make the file xfs_repair complains and resets the sb flag
> - my guess is that in the extent allocation path it is hardcoded for
> the version 4 - any extent allocated beyond file size will get the
> flag ...

Oh, you'd probably need to do this when there are no files already with
the flag, i.e. on a fresh fs I think.

> Also - 2 questions -
> 
> 1) what is inode64 and where can I find out all of the undocumented
> mkfs/mount options (it's unfortunate that such a good fs doesnt' have
> a correspondingly good documentation)

all options for mkfs should be doc'd in the mkfs.xfs manpage

inode64 is also doc'd in my mount manpage:

       inode64
              Indicates  that  XFS  is  allowed to create inodes at any
              location in the filesystem, including  those  which  will
              result  in  inode  numbers occupying more than 32 bits of
              significance.  This is provided for backwards compatibil-
              ity,  but  causes  problems  for backup applications that
              cannot handle large inode numbers.

> 2) why is the largest extent size limited to xxx blocks(can't find
> out thenumber

... various containers that may limit the max size, I don't remember offhand

 - when does the inode get finally flushed? ls -i
> reports 19 as the inode number but even after unmounting inode 19 in
> xfs_db still shows a free inode - is it still only in the log???) ? I
> assumed that xfs_bmap gets me the correct number of extents but now
> looking at the inode with xfs_db it's obvious that xfs_bmap reports
> contiguous ranges rather than actual extents in the blockmap tree

hm, some cut & paste examples might be good here to show us exactly what
you're seeing.

-Eric

<Prev in Thread] Current Thread [Next in Thread>