Steve Lord <lord@xxxxxxx> writes:
> Yep, this flag is never set to anything but zero - even Irix looks that
> way. The question is what should the flag mean - that we are in an
> extent which goes beyond the end of file, it looks like that is the
> intent.
Firstly, my rationale for wanting this flag: I want to allow a nice
easy way for people to add and trim preallocation at the end of file
in libferris. I could assume that if the final extent is a hole then
it is preallocation, but I would really like to know for sure so that
I can issue a XFS_IOC_UNRESVSP64 with a relative feeling that it will
work (given that displaying the size of the unused preallocation at eof
and the user deciding to "trim" it may be seperated by a little time).
I admit that it would be rare for an application to write files
that have a hole at the end that is not left over preallocation, but
if the flag is there to tell if an extent is prealloc then I can know
for sure :)
BTW ferriscreate already has support for making files with preallocation,
this final loop will be handy for ferrisclients to be able to trim back
preallocation that they have not used.
Now some other thoughts:
A quick play around with mkfile and bmap show an interesting thing
[tmp]$ cat dropbyte.c
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
int main( int argc, char** argv )
{
int fd = open("test", O_WRONLY);
printf(" fd:%ld\n", fd );
lseek(fd, 5000, SEEK_SET );
write( fd, "hello", 5 );
close(fd);
}
[tmp]$ /usr/sbin/xfs_mkfile -n -p 128k test
[tmp]$ /usr/sbin/xfs_bmap -vp test
test:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL
0: [0..247]: hole 248
1: [248..255]: 1533656..1533663 1 (764552..764559) 8
[tmp]$ ./dropbyte
fd:3
[tmp]$ /usr/sbin/xfs_bmap -vp test
test:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL
0: [0..7]: hole 8
1: [8..15]: 1186760..1186767 1 (417656..417663) 8
2: [16..247]: hole 232
3: [248..255]: 1533656..1533663 1 (764552..764559) 8
I was always thinking that the "preallocate" flag was an indicator
to tell if that extent was a hole that was there on purpose or if
the hole was part of preallocated space and not really there by
application design. One does land on strange ground in with the last
command because there are two "preallocation" sections, one at the
prefix and one suffix preallocation. This is way I assumed the
XFS_IOC_UNRESVSP64 command took a xfs_flock64_t
typedef struct xfs_flock64 {
__s16 l_type;
__s16 l_whence;
__s64 l_start;
__s64 l_len; /* len == 0 means until end of file */
__s32 l_sysid;
pid_t l_pid;
__s32 l_pad[4]; /* reserve area */
} xfs_flock64_t;
So that one could round up these pesky preallocations that remained only
due to an application seeking and writing.
>
> Steve
>
>
> On Fri, 2002-02-22 at 02:13, monkeyiq wrote:
> > Hi,
> > I emailed this a few weeks ago, but now took a little more
> > of an aggresive attack on the problem and found that from what I
> > can tell BMV_OF_PREALLOC is never set from the linux/fs/xfs kernel
> > calls. Indeed a
> > xfs]$ find . -type f -exec grep BMV_OF_PREALLOC {} \;
> > fails to see anything in the kernel code using that value.
> >
> >
> > in /usr/include/xfs_fs.h #line:133
> > /* bmv_oflags values - returned for for each non-header segment */
> > #define BMV_OF_PREALLOC 0x1 /* segment = unwritten
> > pre-allocation */
> >
> > and I had monstered my private xfs_bmap to output the
> > printf(" bmv_oflags=\"%lld\" ", map[i+1].bmv_oflags);
> > which are always == 0;
> >
> > It seems that from line 5759 in fs/xfs/xfs_bmap.c
> > if ( prealloced
> > && map[i].br_startblock == HOLESTARTBLOCK
> > && out.bmv_offset + out.bmv_length == bmvend) {
> > /*
> > * came to hole at end of file
> > */
> > goto unlock_and_return;
> > } else {
> > that just before the goto maybe
> > if( interface & BMV_IF_PREALLOC )
> > bmv->bmv_oflags |= BMV_OF_PREALLOC;
> >
> > though I have not looked very deeply at the code, it definately
> > seems to be a bug that the oflags are not being set.
> >
> > --
> > -----------------------------------------------------
> > http://witme.sourceforge.net/libferris.web/
> --
>
> Steve Lord voice: +1-651-683-3511
> Principal Engineer, Filesystem Software email: lord@xxxxxxx
>
--
-----------------------------------------------------
http://witme.sourceforge.net/libferris.web/
|