Re: fcntl(fd,F_SETSIZE,?)
Re: fcntl(fd,F_SETSIZE,?)
- Subject: Re: fcntl(fd,F_SETSIZE,?)
- From: James Bucanek <email@hidden>
- Date: Fri, 12 Oct 2012 14:50:13 -0700
Ken,
Thanks for the insight and the ideas.
My previous problem with preallocation was primarily with AFS.
When used with a networked volume, the Carbon FSAllocateFork
function would return successful (i.e. it DID preallocate),
although no space was actually allocated. So I couldn't tell
whether space was actually allocated or not, even though the
function has a specific return value to indicate that it did
not, or can not, preallocate space. I filed a bug on this and it
was closed with "as designed," which still has me scratching my head.
I'm need to write some test code this afternoon to explore
whether the volume capability flag VOL_CAP_INT_ALLOCATE accurate
reflects the volume's ability to preallocate space on networked
AFS volumes. If it does, then I'll probably return to using
preallocation. If not, then I'll continue to struggle to find a
working solution. :)
I'm also intrigued by what I just read about lseek(): that you
can position and write data beyond the logical EOF and the
filesystem will dynamically fill in zeros for the bytes
in-between. This is causing me to rethink how I write some of my
sparse index files, and might be a better workaround than trying
to set the EOF first.
Again, thanks for the all of the great feedback and advice.
James
Ken Hornstein <mailto:email@hidden> wrote (Friday,
October 12, 2012 12:54 PM -0400):
This wasn't, specifically, for HFS+. This was an experiment to
find an alternative to pre-allocation, since the
pre-allocation on some filesystems (AFS specifically) is broken.
I am not sure there is a specific pre-allocation RPC in AFS (actually,
I am reasonably sure there is not), so I wondering what's really
going on there.
Okay, assuming that "pre-allocate" does something equivalent as
ftruncate() does ... I'm wondering what's happening? All ftruncate
does is call vnode_setattr() with the "correct" length. It doesn't
do any extra writing. And I just did a network trace where I called
ftruncate() on a file in AFS and it ended up issuing only a single
RPC, not a complete series of zero-byte writes. So if you're using
ftruncate() it looks to me like preallocation works just fine in
AFS; according to ls, the file is not a sparse file at all.
Okay, scratch that ... it looks like what AFS does is simply return
for the blocks of a file is "size / blocksize", so there's not an
easy way of determining whether or not a file is sparse. And I see
that there's not really a portable way of doing this; there is a
posix_fallocate() function, but it seems like MacOS X doesn't
implement it.
On AFS particularly, if you open a file and set its EOF (in
Carbon) it stops to write zeros before returning.
I am wondering if this was just a poor interaction with the Carbon API.
As Shantou already hinted, Carbon is sort of magical ... a system call
trace will show you that it does a lot of stuff in the /.vol directory.
I do wonder what Carbon is doing behind the scenes, but if you're just
using ftruncate() with AFS it should work fine.
--Ken
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
James Bucanek
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden