Re: fcntl(fd,F_SETSIZE,?)
Re: fcntl(fd,F_SETSIZE,?)
- Subject: Re: fcntl(fd,F_SETSIZE,?)
- From: Ken Hornstein <email@hidden>
- Date: Fri, 12 Oct 2012 15:54:36 -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