On Tue, Mar 06, 2007 at 10:46:56AM -0600, Eric Sandeen wrote:
> Ulrich Drepper wrote:
> > Christoph Hellwig wrote:
> >> fallocate with the whence argument and flags is already quite complicated,
> >> I'd rather have another call for placement decisions, that would
> >> be called on an fd to do plac
On Wed, 7 March 2007 09:51:35 +0100, Jan Kara wrote:
>
> I'll probably first write some userspace fs-reorganizer to find out how
> much these changes in layout are able to give you in performance (i.e.
> whether it's worth the effort of more complicated kernel online
> defragmenter).
Have tried
On Tue 06-03-07 12:23:22, Eric Sandeen wrote:
> Jan Kara wrote:
> > On Tue 06-03-07 06:36:09, Ulrich Drepper wrote:
> >> Christoph Hellwig wrote:
> >>> fallocate with the whence argument and flags is already quite complicated,
> >>> I'd rather have another call for placement decisions, that would
>
Jan Kara wrote:
> On Tue 06-03-07 06:36:09, Ulrich Drepper wrote:
>> Christoph Hellwig wrote:
>>> fallocate with the whence argument and flags is already quite complicated,
>>> I'd rather have another call for placement decisions, that would
>>> be called on an fd to do placement decissions for any
Ulrich Drepper wrote:
> Christoph Hellwig wrote:
>> fallocate with the whence argument and flags is already quite complicated,
>> I'd rather have another call for placement decisions, that would
>> be called on an fd to do placement decissions for any further allocations
>> (prealloc, write, etc)
>
On Tue, Mar 06, 2007 at 06:36:09AM -0800, Ulrich Drepper wrote:
> Christoph Hellwig wrote:
> > fallocate with the whence argument and flags is already quite complicated,
> > I'd rather have another call for placement decisions, that would
> > be called on an fd to do placement decissions for any fu
On Tue 06-03-07 06:36:09, Ulrich Drepper wrote:
> Christoph Hellwig wrote:
> > fallocate with the whence argument and flags is already quite complicated,
> > I'd rather have another call for placement decisions, that would
> > be called on an fd to do placement decissions for any further allocation
Christoph Hellwig wrote:
> fallocate with the whence argument and flags is already quite complicated,
> I'd rather have another call for placement decisions, that would
> be called on an fd to do placement decissions for any further allocations
> (prealloc, write, etc)
Yes, posix_fallocate shouldn
On Mon, Mar 05, 2007 at 12:02:59PM -0800, Mingming Cao wrote:
> Yep, I think it makes sense to use preallocation for defragmentation.
> After all both preallocation and defragmentation shall call underlying
> filesystem multiple block allocator to try to allocate a chunk of
> contiguous blocks on
Jörn Engel wrote:
> Does the allocation have to be persistent beyond lifetime of the file
> descriptor? It would be fairly simple to support the write guarantee
> while the file is open (or rather the inode remains cached) and drop it
> afterwards.
"The posix_fallocate() function shall ensure tha
Jan Kara wrote:
>> I am wondering if it is useful to add another mode to advise block
>> allocation policy? Something like indicating which physical block/block
>> group to allocate from (goal), and whether ask for strict contigous
>> blocks. This will help preallocation or reservation to choos
Jan Kara wrote:
On Fri, 02 Mar 2007 09:40:54 +1100
Nathan Scott <[EMAIL PROTECTED]> wrote:
On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
On Fri, 2 Mar 2007 00:04:45 +0530
"Amit K. Arora" <[EMAIL PROTECTED]> wrote:
This is to give a heads up on few patches that we will be soon
Theodore Tso wrote:
> [...] although the libc
> implementation still wouldn't be able to go away for long time due to
> the need to be backwards compatible with older kernels that didn't
> have this support.
It's better than that. If somebody compiles glibc to not run on older
kernels at all (tes
On Mon, Mar 05, 2007 at 07:15:33AM -0800, Ulrich Drepper wrote:
> Well, I'm sure the kernel can do better than the code we have in libc
> now. The kernel has access to the bitmasks which say which blocks have
> already been allocated. The libc code does not and we have to be very
> simple-minded
Jörn Engel wrote:
>> Of course. You call posix_fallocate once for the lifetime of the file
>> when it is created to ensure that all future uses will work.
>
> That part is not quite clear from the manpage but I trust most people
> would assume the same.
Not only that, it is what this function is
On Mon, 5 March 2007 07:08:03 -0800, Ulrich Drepper wrote:
> Jörn Engel wrote:
> > Does the allocation have to be persistent beyond lifetime of the file
> > descriptor?
>
> Of course. You call posix_fallocate once for the lifetime of the file
> when it is created to ensure that all future uses wi
On Mon, Mar 05, 2007 at 07:15:33AM -0800, Ulrich Drepper wrote:
> Theodore Tso wrote:
> > Given that glibc already has to support this for older kernels, I
> > would argue that there's no point putting in generic support for
> > filesystem that can't support a more advanced way of doing things.
>
Jörn Engel wrote:
> The bad news for posix_fallocate() is that even if libc is smart enough
> to write random data, mmap() can still cause problems.
This is not smart, quite to the contrary. The standard guarantees that
all not-yet-written-to places in the file are zero. And if a block has
alrea
Jörn Engel wrote:
> Does the allocation have to be persistent beyond lifetime of the file
> descriptor?
Of course. You call posix_fallocate once for the lifetime of the file
when it is created to ensure that all future uses will work.
It seems your filesystem will not be able to support this unl
Theodore Tso wrote:
> Given that glibc already has to support this for older kernels, I
> would argue that there's no point putting in generic support for
> filesystem that can't support a more advanced way of doing things.
Well, I'm sure the kernel can do better than the code we have in libc
now.
On 5 Mar 2007, at 14:37, Theodore Tso wrote:
On Sun, Mar 04, 2007 at 11:22:06PM +, Anton Altaparmakov wrote:
And I specifically did NOT update the initialized size in the inode
thus it will remain at its old value thus all new allocated blocks
will be considered as present but not initialize
On Sun, Mar 04, 2007 at 11:22:06PM +, Anton Altaparmakov wrote:
> And I specifically did NOT update the initialized size in the inode
> thus it will remain at its old value thus all new allocated blocks
> will be considered as present but not initialized thus a read will
> always return z
On Mon, 5 March 2007 00:32:14 +, Anton Altaparmakov wrote:
>
> I don't know how your compression algorithm works [...]
LogFS is designed for flash media, so it does not have to worry much
about reducing disk seeks. It is log-structured, which simplifies
compression further.
When writing a b
On Sat, Mar 03, 2007 at 11:45:32PM +0100, Arnd Bergmann wrote:
> > I'd be more happy to have the write out zeroes loop in glibc. ?And
> > glibc needs to have it anyway, for older kernels.
>
> A generic_fallocate makes sense to me iff we can do it in the kernel
> more significantly more efficiently
On Mon, 5 March 2007 01:36:36 +0100, Arnd Bergmann wrote:
>
> Using the current glibc implementation on a compressed file system ideally
> should be a very expensive no-op because you won't actually allocate much
> space for a file when writing zeroes to it. You also don't benefit of a
> contiguou
> >On Fri, 02 Mar 2007 09:40:54 +1100
> >Nathan Scott <[EMAIL PROTECTED]> wrote:
> >
> >
> >>On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
> >>
> >>>On Fri, 2 Mar 2007 00:04:45 +0530
> >>>"Amit K. Arora" <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> This is to give a heads up on few patche
On Sun, Mar 04, 2007 at 08:11:17PM +, Anton Altaparmakov wrote:
> glibc cannot ever be smart enough because a file system driver will
> always know better and be able to do things in a much more optimized
> way.
Please read the thread again. That is not what anyone proposed.
The issues we
On Sun, 4 March 2007 14:38:13 -0800, Ulrich Drepper wrote:
>
> When you do it like this, who can the kernel/filesystem *guarantee* that
> when the data is written there actually is room on the harddrive?
>
> What you described seems like using truncate/ftruncate to increase the
> file's size. Th
On Monday 05 March 2007, Anton Altaparmakov wrote:
> An alternative would be to allocate blocks and then when the data is
> written perform the compression and free any blocks you do not need
> any more because the data has shrunk sufficiently. Depending on the
> implementation details this
On Monday 05 March 2007, Jörn Engel wrote:
> That actually causes an interesting problem for compressing filesystems.
> The space consumed by blocks depends on their contents and how well it
> compresses. At the moment, the only option I see to support
> posix_fallocate for LogFS is to set an inod
On 5 Mar 2007, at 00:32, Anton Altaparmakov wrote:
On 5 Mar 2007, at 00:16, Jörn Engel wrote:
On Sun, 4 March 2007 14:38:13 -0800, Ulrich Drepper wrote:
When you do it like this, who can the kernel/filesystem
*guarantee* that
when the data is written there actually is room on the harddrive?
On 5 Mar 2007, at 00:16, Jörn Engel wrote:
On Sun, 4 March 2007 14:38:13 -0800, Ulrich Drepper wrote:
When you do it like this, who can the kernel/filesystem
*guarantee* that
when the data is written there actually is room on the harddrive?
What you described seems like using truncate/ftr
Hi,
On 4 Mar 2007, at 22:38, Ulrich Drepper wrote:
Anton Altaparmakov wrote:
And that is it. No zeroing needs to happen at all because we
have not updated the initialized size of the inode!
When you do it like this, who can the kernel/filesystem *guarantee*
that
when the data is written t
Anton Altaparmakov wrote:
> And that is it. No zeroing needs to happen at all because we
> have not updated the initialized size of the inode!
When you do it like this, who can the kernel/filesystem *guarantee* that
when the data is written there actually is room on the harddrive?
What you descr
On Sunday 04 March 2007, Anton Altaparmakov wrote:
> > A generic_fallocate makes sense to me iff we can do it in the kernel
> > more significantly more efficiently than in glibc, e.g. by using only
> > a single page in page cache instead of one for each page to be
> > preallocated.
> >
> > If gl
On 3 Mar 2007, at 22:45, Arnd Bergmann wrote:
On Friday 02 March 2007 00:38:19 Christoph Hellwig wrote:
Forgive me if I haven't put enough thought into it, but would it be
useful to create a generic_fallocate() that writes zeroed pages
for any
non-existent pages in the range? I don't know ho
On Friday 02 March 2007 00:38:19 Christoph Hellwig wrote:
> > Forgive me if I haven't put enough thought into it, but would it be
> > useful to create a generic_fallocate() that writes zeroed pages for any
> > non-existent pages in the range? I don't know how glibc currently
> > implements posix_f
Andrew Morton wrote:
On Fri, 02 Mar 2007 09:40:54 +1100
Nathan Scott <[EMAIL PROTECTED]> wrote:
On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
On Fri, 2 Mar 2007 00:04:45 +0530
"Amit K. Arora" <[EMAIL PROTECTED]> wrote:
This is to give a heads up on few patches that we will be s
Dave Kleikamp wrote:
On Thu, 2007-03-01 at 14:59 -0800, Andrew Morton wrote:
On Thu, 01 Mar 2007 22:44:16 +
Dave Kleikamp <[EMAIL PROTECTED]> wrote:
On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
On Fri, 2 Mar 2007 00:04:45 +0530
"Amit K. Arora" <[EMAIL PROTECTED]> wrote:
+
Badari Pulavarty wrote:
BTW, what is the interface for finding out what is the size of the
pre-allocated file ?
With XFS at least, "du," "stat," etc tell you a little:
[EMAIL PROTECTED] test]# touch resvsp
[EMAIL PROTECTED] test]# xfs_io resvsp
xfs_io> resvsp 0 10g
The file is 0 length, but
On Fri, 02 Mar 2007 08:13:00 -0800 Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> >
> > > What about
> > > if the
> > > blocks already exists ? What would be return values in those cases ?
> >
> > 0 on success, other normal errors oetherwise..
> >
> > If asked for a range that includes already-
On Fri, 2007-03-02 at 09:16 -0600, Eric Sandeen wrote:
> Badari Pulavarty wrote:
> >
> > Amit K. Arora wrote:
> >
> >> This is to give a heads up on few patches that we will be soon coming up
> >> with. These patches implement a new system call sys_fallocate() and a
> >> new inode operation "fall
Badari Pulavarty wrote:
Amit K. Arora wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode operation "fallocate", for persistent preallocation. The new
system call, as Andrew suggested, w
On 3/2/07, Dave Kleikamp <[EMAIL PROTECTED]> wrote:
Then there's no need for sys_allocate to return a long.
Every syscall must return a long. Otherwise you can have problems on
64-bit archs.
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [EM
On Mar 1 2007 23:09, Dave Kleikamp wrote:
>>
>> Given that glibc already implements fallocate for all filesystems, it will
>> need to continue to do so for filesystems which don't implement this
>> syscall - otherwise applications would start breaking.
>
>I didn't make it clear, but my point was
Amit wrote:
> asmlinkage long sys_fallocate(int fd, loff_t offset, loff_t len);
On Thu, 2007-03-01 at 22:16 -0800, Andrew Morton wrote:
> On Thu, 01 Mar 2007 22:03:55 -0800 Badari Pulavarty <[EMAIL PROTECTED]> wrote:
>
> > Just curious .. What does posix_fallocate() return ?
>
> bookmark this:
On Fri, 2007-03-02 at 18:45 +0800, Andreas Dilger wrote:
> On Mar 01, 2007 13:15 -0600, Eric Sandeen wrote:
> > One thing I'd like to see is a cmd argument as well, to allow for
> > example allocation vs. reservation (i.e. allocating blocks vs. simply
> > reserving a number), as well as the inve
On Mar 01, 2007 13:15 -0600, Eric Sandeen wrote:
> One thing I'd like to see is a cmd argument as well, to allow for
> example allocation vs. reservation (i.e. allocating blocks vs. simply
> reserving a number), as well as the inverse of those functions
> (un-reservation, de-allocation)?
>
> I
Andrew Morton wrote:
> Perhaps Ulrich can comment.
I was out of town, hence the delay.
I think that if there is no support for the syscall the correct answer
is to return ENOSYS. In this case the current userlevel code would be
used and ENOSYS is also used to trigger the use of the compat code i
On Thu, 01 Mar 2007 22:03:55 -0800 Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> Just curious .. What does posix_fallocate() return ?
bookmark this:
http://www.opengroup.org/onlinepubs/009695399/nfindex.html
Upon successful completion, posix_fallocate() shall return zero;
otherwise, an
Amit K. Arora wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode operation "fallocate", for persistent preallocation. The new
system call, as Andrew suggested, will look like:
asmlinka
On Thu, Mar 01, 2007 at 05:29:15PM -0600, Eric Sandeen wrote:
> Amit K. Arora wrote:
>
> Might want more error checking in there, something like (rough cut)...
> (or is some of this glibc's job?)
Yeah, we need to have this checks. We can't rely on userspace not
passing arguments that might corru
On Thu, Mar 01, 2007 at 10:44:16PM +, Dave Kleikamp wrote:
> Would EINVAL (or whatever) make it back to the caller of
> posix_fallocate(), or would glibc fall back to its current
> implementation?
>
> Forgive me if I haven't put enough thought into it, but would it be
> useful to create a gene
On Fri, Mar 02, 2007 at 12:04:45AM +0530, Amit K. Arora wrote:
> This is to give a heads up on few patches that we will be soon coming up
> with. These patches implement a new system call sys_fallocate() and a
> new inode operation "fallocate", for persistent preallocation. The new
> system call, a
Amit K. Arora wrote:
Might want more error checking in there, something like (rough cut)...
(or is some of this glibc's job?)
+asmlinkage long sys_fallocate(int fd, loff_t offset, loff_t len)
+{
+ struct file *file;
+ struct inode *inode;
+ long ret;
> +
> + ret = -EINVAL;
>
On Thu, 2007-03-01 at 14:59 -0800, Andrew Morton wrote:
> On Thu, 01 Mar 2007 22:44:16 +
> Dave Kleikamp <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
> > > On Fri, 2 Mar 2007 00:04:45 +0530
> > > "Amit K. Arora" <[EMAIL PROTECTED]> wrote:
> >
> > >
On Thu, 01 Mar 2007 22:44:16 +
Dave Kleikamp <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
> > On Fri, 2 Mar 2007 00:04:45 +0530
> > "Amit K. Arora" <[EMAIL PROTECTED]> wrote:
>
> > > +asmlinkage long sys_fallocate(int fd, loff_t offset, loff_t len)
> >
On Fri, 02 Mar 2007 09:40:54 +1100
Nathan Scott <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
> > On Fri, 2 Mar 2007 00:04:45 +0530
> > "Amit K. Arora" <[EMAIL PROTECTED]> wrote:
> >
> > > This is to give a heads up on few patches that we will be soon coming
On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
> On Fri, 2 Mar 2007 00:04:45 +0530
> "Amit K. Arora" <[EMAIL PROTECTED]> wrote:
> > +asmlinkage long sys_fallocate(int fd, loff_t offset, loff_t len)
> > +{
> > + struct file *file;
> > + struct inode *inode;
> > + long ret = -EINVAL;
> That new argument might need to come after "fd" - ARM has funny
> requirements on syscall arg padding and layout.
FYI the 32bit ppc ABI does too, from arch/powerpc/kernel/sys_ppc32.c:
/*
* long long munging:
* The 32 bit ABI passes long longs in an odd even register pair.
*/
and the first
Nathan Scott wrote:
On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
On Fri, 2 Mar 2007 00:04:45 +0530
"Amit K. Arora" <[EMAIL PROTECTED]> wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and
On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
> On Fri, 2 Mar 2007 00:04:45 +0530
> "Amit K. Arora" <[EMAIL PROTECTED]> wrote:
>
> > This is to give a heads up on few patches that we will be soon coming up
> > with. These patches implement a new system call sys_fallocate() and a
> > new
On Fri, 2 Mar 2007 00:04:45 +0530
"Amit K. Arora" <[EMAIL PROTECTED]> wrote:
> This is to give a heads up on few patches that we will be soon coming up
> with. These patches implement a new system call sys_fallocate() and a
> new inode operation "fallocate", for persistent preallocation. The new
>
Alan wrote:
> ENOSYS indicates quite different things and ENOTTY is also used for
> syscalls. I still think ENOTTY is correct.
>
Yes, ENOSYS tends to me "operation flat out not support" rather than
"not on this object". I think we can do better than ENOTTY though -
ENOTSUP for example (modulo t
On Thu, 01 Mar 2007 14:05:36 -0800
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Alan wrote:
> > A lot of people get confused about -ENOTTY, but it is the return for
> > attempting to use an ioctl on the wrong type of object, so this appears
> > to be quite correct.
>
> This is a syscall thoug
Alan wrote:
> A lot of people get confused about -ENOTTY, but it is the return for
> attempting to use an ioctl on the wrong type of object, so this appears
> to be quite correct.
This is a syscall though; ENOSYS is probably a better match.
J
-
To unsubscribe from this list: send the line "un
On Thu, 01 Mar 2007 13:14:32 -0800
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Amit K. Arora wrote:
> > + if (inode->i_op && inode->i_op->fallocate)
> > + ret = inode->i_op->fallocate(inode, offset, len);
> > + else
> > + ret = -ENOTTY;
>
> You can only allocate space
Amit K. Arora wrote:
> + if (inode->i_op && inode->i_op->fallocate)
> + ret = inode->i_op->fallocate(inode, offset, len);
> + else
> + ret = -ENOTTY;
You can only allocate space on typewriters? ;)
J
-
To unsubscribe from this list: send the line "unsubscribe li
On Thu, Mar 01, 2007 at 03:23:19PM -0500, Jeff Garzik wrote:
> I certainly agree that we want something like this.
>
> posix_fallocate() is the glibc interface we want to be compatible with
> (which your definition is, AFAICS).
This would be great for Samba. Windows clients do this a lot
Je
Amit K. Arora wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode operation "fallocate", for persistent preallocation. The new
system call, as Andrew suggested, will look like:
asmlinkag
Amit K. Arora wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode operation "fallocate", for persistent preallocation. The new
system call, as Andrew suggested, will look like:
asmlinkag
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode operation "fallocate", for persistent preallocation. The new
system call, as Andrew suggested, will look like:
asmlinkage long sys_fallocate(in
72 matches
Mail list logo
