On Thu, Jun 14, 2007 at 03:14:58AM -0600, Andreas Dilger wrote:
> I suppose it might be a bit late in the game to add a "goal"
> parameter and e.g. FA_FL_REQUIRE_GOAL, FA_FL_NEAR_GOAL, etc to make
> the API more suitable for XFS? The goal could be a single __u64, or
> a struct with e.g. __u64
On Thu, Jun 14, 2007 at 03:14:58AM -0600, Andreas Dilger wrote:
I suppose it might be a bit late in the game to add a goal
parameter and e.g. FA_FL_REQUIRE_GOAL, FA_FL_NEAR_GOAL, etc to make
the API more suitable for XFS? The goal could be a single __u64, or
a struct with e.g. __u64 byte
On Jun 14, 2007 22:04 +1000, David Chinner wrote:
> On Thu, Jun 14, 2007 at 03:14:58AM -0600, Andreas Dilger wrote:
> > > B FA_DEALLOCATE
> > > removes the underlying disk space with the given range. The disk space
> > > shall be removed regardless of it's contents so both allocated space
> > >
On Thu, Jun 14, 2007 at 03:14:58AM -0600, Andreas Dilger wrote:
> On Jun 14, 2007 09:52 +1000, David Chinner wrote:
> > B FA_PREALLOCATE
> > provides the same functionality as
> > B FA_ALLOCATE
> > except it does not ever change the file size. This allows allocation
> > of zero blocks beyond the
On Jun 14, 2007 09:52 +1000, David Chinner wrote:
> B FA_PREALLOCATE
> provides the same functionality as
> B FA_ALLOCATE
> except it does not ever change the file size. This allows allocation
> of zero blocks beyond the end of file and is useful for optimising
> append workloads.
> TP
> B
On Jun 14, 2007 09:52 +1000, David Chinner wrote:
B FA_PREALLOCATE
provides the same functionality as
B FA_ALLOCATE
except it does not ever change the file size. This allows allocation
of zero blocks beyond the end of file and is useful for optimising
append workloads.
TP
B FA_DEALLOCATE
On Thu, Jun 14, 2007 at 03:14:58AM -0600, Andreas Dilger wrote:
On Jun 14, 2007 09:52 +1000, David Chinner wrote:
B FA_PREALLOCATE
provides the same functionality as
B FA_ALLOCATE
except it does not ever change the file size. This allows allocation
of zero blocks beyond the end of file
On Jun 14, 2007 22:04 +1000, David Chinner wrote:
On Thu, Jun 14, 2007 at 03:14:58AM -0600, Andreas Dilger wrote:
B FA_DEALLOCATE
removes the underlying disk space with the given range. The disk space
shall be removed regardless of it's contents so both allocated space
from
B
On Tue, Jun 12, 2007 at 11:46:52AM +0530, Amit K. Arora wrote:
> Did you get time to write the above man page ? It will help to push
> further patches in time (eg. for FA_PREALLOCATE mode).
First pass is attached.
`nroff -man fallocate.2 | less` to view.
Cheers,
Dave.
--
Dave Chinner
On Tue, Jun 12, 2007 at 11:46:52AM +0530, Amit K. Arora wrote:
Did you get time to write the above man page ? It will help to push
further patches in time (eg. for FA_PREALLOCATE mode).
First pass is attached.
`nroff -man fallocate.2 | less` to view.
Cheers,
Dave.
--
Dave Chinner
Principal
On Tue, Jun 12, 2007 at 11:46:52AM +0530, Amit K. Arora wrote:
> On Sat, May 12, 2007 at 06:01:57PM +1000, David Chinner wrote:
> > Minimal definition to replace what applicaitons use on XFS and to
> > support poasix_fallocate are the thre that have been mentioned so
> > far (FA_ALLOCATE,
On Sat, May 12, 2007 at 06:01:57PM +1000, David Chinner wrote:
> On Fri, May 11, 2007 at 04:33:01PM +0530, Suparna Bhattacharya wrote:
> > On Fri, May 11, 2007 at 08:39:50AM +1000, David Chinner wrote:
> > > All I'm really interested in right now is that the fallocate
> > > _interface_ can be used
On Sat, May 12, 2007 at 06:01:57PM +1000, David Chinner wrote:
On Fri, May 11, 2007 at 04:33:01PM +0530, Suparna Bhattacharya wrote:
On Fri, May 11, 2007 at 08:39:50AM +1000, David Chinner wrote:
All I'm really interested in right now is that the fallocate
_interface_ can be used as a
On Tue, Jun 12, 2007 at 11:46:52AM +0530, Amit K. Arora wrote:
On Sat, May 12, 2007 at 06:01:57PM +1000, David Chinner wrote:
Minimal definition to replace what applicaitons use on XFS and to
support poasix_fallocate are the thre that have been mentioned so
far (FA_ALLOCATE, FA_PREALLOCATE,
On Fri, May 11, 2007 at 04:33:01PM +0530, Suparna Bhattacharya wrote:
> On Fri, May 11, 2007 at 08:39:50AM +1000, David Chinner wrote:
> > All I'm really interested in right now is that the fallocate
> > _interface_ can be used as a *complete replacement* for the
> > pre-existing XFS-specific
On Fri, May 11, 2007 at 04:33:01PM +0530, Suparna Bhattacharya wrote:
On Fri, May 11, 2007 at 08:39:50AM +1000, David Chinner wrote:
All I'm really interested in right now is that the fallocate
_interface_ can be used as a *complete replacement* for the
pre-existing XFS-specific ioctls that
On Fri, May 11, 2007 at 08:39:50AM +1000, David Chinner wrote:
> On Thu, May 10, 2007 at 05:26:20PM +0530, Amit K. Arora wrote:
> > On Thu, May 10, 2007 at 10:59:26AM +1000, David Chinner wrote:
> > > On Wed, May 09, 2007 at 09:31:02PM +0530, Amit K. Arora wrote:
> > > > I have the updated patches
On Fri, May 11, 2007 at 08:39:50AM +1000, David Chinner wrote:
On Thu, May 10, 2007 at 05:26:20PM +0530, Amit K. Arora wrote:
On Thu, May 10, 2007 at 10:59:26AM +1000, David Chinner wrote:
On Wed, May 09, 2007 at 09:31:02PM +0530, Amit K. Arora wrote:
I have the updated patches ready
On Thu, May 10, 2007 at 05:26:20PM +0530, Amit K. Arora wrote:
> On Thu, May 10, 2007 at 10:59:26AM +1000, David Chinner wrote:
> > On Wed, May 09, 2007 at 09:31:02PM +0530, Amit K. Arora wrote:
> > > I have the updated patches ready which take care of Andrew's comments.
> > > Will run some tests
On Thu, May 10, 2007 at 10:59:26AM +1000, David Chinner wrote:
> On Wed, May 09, 2007 at 09:31:02PM +0530, Amit K. Arora wrote:
> > I have the updated patches ready which take care of Andrew's comments.
> > Will run some tests and post them soon.
> >
> > But, before submitting these patches, I
On Thu, May 10, 2007 at 10:59:26AM +1000, David Chinner wrote:
On Wed, May 09, 2007 at 09:31:02PM +0530, Amit K. Arora wrote:
I have the updated patches ready which take care of Andrew's comments.
Will run some tests and post them soon.
But, before submitting these patches, I think it
On Thu, May 10, 2007 at 05:26:20PM +0530, Amit K. Arora wrote:
On Thu, May 10, 2007 at 10:59:26AM +1000, David Chinner wrote:
On Wed, May 09, 2007 at 09:31:02PM +0530, Amit K. Arora wrote:
I have the updated patches ready which take care of Andrew's comments.
Will run some tests and post
On Wed, May 09, 2007 at 09:31:02PM +0530, Amit K. Arora wrote:
> I have the updated patches ready which take care of Andrew's comments.
> Will run some tests and post them soon.
>
> But, before submitting these patches, I think it will be better to finalize
> on certain things which might be
On Wed, 2007-05-09 at 21:31 +0530, Amit K. Arora wrote:
> I have the updated patches ready which take care of Andrew's comments.
> Will run some tests and post them soon.
>
> But, before submitting these patches, I think it will be better to finalize
> on certain things which might be worth some
On May 09, 2007 21:31 +0530, Amit K. Arora wrote:
> 2) For FA_UNALLOCATE mode, should the file system allow unallocation
>of normal (non-preallocated) blocks (blocks allocated via
>regular write/truncate operations) also (i.e. work as punch()) ?
>- Though FA_UNALLOCATE mode is yet to
I have the updated patches ready which take care of Andrew's comments.
Will run some tests and post them soon.
But, before submitting these patches, I think it will be better to finalize
on certain things which might be worth some discussion here:
1) Should the file size change when
On Wed, May 09, 2007 at 09:37:22PM +1000, Paul Mackerras wrote:
> Suparna Bhattacharya writes:
>
> > > Of course the interface used by an application program would have the
> > > fd first. Glibc can do the translation.
> >
> > I think that was understood.
>
> OK, then what does it matter what
On 5/9/07, Paul Mackerras <[EMAIL PROTECTED]> wrote:
Suparna Bhattacharya writes:
> > Of course the interface used by an application program would have the
> > fd first. Glibc can do the translation.
>
> I think that was understood.
OK, then what does it matter what the glibc/kernel interface
Suparna Bhattacharya writes:
> > Of course the interface used by an application program would have the
> > fd first. Glibc can do the translation.
>
> I think that was understood.
OK, then what does it matter what the glibc/kernel interface is, as
long as it works?
It's only a minor point;
On Wed, May 09, 2007 at 08:50:44PM +1000, Paul Mackerras wrote:
> Suparna Bhattacharya writes:
>
> > > This looks like it will have the same problem on s390 as
> > > sys_sync_file_range. Maybe the prototype should be:
> > >
> > > asmlinkage long sys_fallocate(loff_t offset, loff_t len, int fd,
Suparna Bhattacharya writes:
> > This looks like it will have the same problem on s390 as
> > sys_sync_file_range. Maybe the prototype should be:
> >
> > asmlinkage long sys_fallocate(loff_t offset, loff_t len, int fd, int mode)
>
> Yes, but the trouble is that there was a contrary viewpoint
On Fri, May 04, 2007 at 02:41:50PM +1000, Paul Mackerras wrote:
> Andrew Morton writes:
>
> > On Thu, 26 Apr 2007 23:33:32 +0530 "Amit K. Arora" <[EMAIL PROTECTED]>
> > wrote:
> >
> > > This patch implements the fallocate() system call and adds support for
> > > i386, x86_64 and powerpc.
> > >
On Fri, May 04, 2007 at 02:41:50PM +1000, Paul Mackerras wrote:
Andrew Morton writes:
On Thu, 26 Apr 2007 23:33:32 +0530 Amit K. Arora [EMAIL PROTECTED]
wrote:
This patch implements the fallocate() system call and adds support for
i386, x86_64 and powerpc.
...
Suparna Bhattacharya writes:
This looks like it will have the same problem on s390 as
sys_sync_file_range. Maybe the prototype should be:
asmlinkage long sys_fallocate(loff_t offset, loff_t len, int fd, int mode)
Yes, but the trouble is that there was a contrary viewpoint preferring
On Wed, May 09, 2007 at 08:50:44PM +1000, Paul Mackerras wrote:
Suparna Bhattacharya writes:
This looks like it will have the same problem on s390 as
sys_sync_file_range. Maybe the prototype should be:
asmlinkage long sys_fallocate(loff_t offset, loff_t len, int fd, int mode)
Suparna Bhattacharya writes:
Of course the interface used by an application program would have the
fd first. Glibc can do the translation.
I think that was understood.
OK, then what does it matter what the glibc/kernel interface is, as
long as it works?
It's only a minor point; the
On 5/9/07, Paul Mackerras [EMAIL PROTECTED] wrote:
Suparna Bhattacharya writes:
Of course the interface used by an application program would have the
fd first. Glibc can do the translation.
I think that was understood.
OK, then what does it matter what the glibc/kernel interface is, as
On Wed, May 09, 2007 at 09:37:22PM +1000, Paul Mackerras wrote:
Suparna Bhattacharya writes:
Of course the interface used by an application program would have the
fd first. Glibc can do the translation.
I think that was understood.
OK, then what does it matter what the
I have the updated patches ready which take care of Andrew's comments.
Will run some tests and post them soon.
But, before submitting these patches, I think it will be better to finalize
on certain things which might be worth some discussion here:
1) Should the file size change when
On May 09, 2007 21:31 +0530, Amit K. Arora wrote:
2) For FA_UNALLOCATE mode, should the file system allow unallocation
of normal (non-preallocated) blocks (blocks allocated via
regular write/truncate operations) also (i.e. work as punch()) ?
- Though FA_UNALLOCATE mode is yet to be
On Wed, 2007-05-09 at 21:31 +0530, Amit K. Arora wrote:
I have the updated patches ready which take care of Andrew's comments.
Will run some tests and post them soon.
But, before submitting these patches, I think it will be better to finalize
on certain things which might be worth some
On Wed, May 09, 2007 at 09:31:02PM +0530, Amit K. Arora wrote:
I have the updated patches ready which take care of Andrew's comments.
Will run some tests and post them soon.
But, before submitting these patches, I think it will be better to finalize
on certain things which might be worth
Jakub Jelinek wrote:
is what glibc does ATM. Seems we violate the case where len == 0, as
EINVAL in that case is "shall fail". But reading the standard to imply
negative len is ok is too much guessing, there is no word what it means
when len is negative and
"required storage for regular file
On Thu, May 03, 2007 at 11:28:15PM -0700, Andrew Morton wrote:
> The above opengroup page only permits S_ISREG. Preallocating directories
> sounds quite useful to me, although it's something which would be pretty
> hard to emulate if the FS doesn't support it. And there's a decent case to
> be
Andrew,
Thanks for the review comments!
On Thu, May 03, 2007 at 09:29:55PM -0700, Andrew Morton wrote:
> On Thu, 26 Apr 2007 23:33:32 +0530 "Amit K. Arora" <[EMAIL PROTECTED]> wrote:
>
> > This patch implements the fallocate() system call and adds support for
> > i386, x86_64 and powerpc.
> >
Andrew,
Thanks for the review comments!
On Thu, May 03, 2007 at 09:29:55PM -0700, Andrew Morton wrote:
On Thu, 26 Apr 2007 23:33:32 +0530 Amit K. Arora [EMAIL PROTECTED] wrote:
This patch implements the fallocate() system call and adds support for
i386, x86_64 and powerpc.
...
On Thu, May 03, 2007 at 11:28:15PM -0700, Andrew Morton wrote:
The above opengroup page only permits S_ISREG. Preallocating directories
sounds quite useful to me, although it's something which would be pretty
hard to emulate if the FS doesn't support it. And there's a decent case to
be made
Jakub Jelinek wrote:
is what glibc does ATM. Seems we violate the case where len == 0, as
EINVAL in that case is shall fail. But reading the standard to imply
negative len is ok is too much guessing, there is no word what it means
when len is negative and
required storage for regular file data
On Thu, May 03, 2007 at 11:28:15PM -0700, Andrew Morton wrote:
> On Fri, 4 May 2007 16:07:31 +1000 David Chinner <[EMAIL PROTECTED]> wrote:
> > On Thu, May 03, 2007 at 09:29:55PM -0700, Andrew Morton wrote:
> > > On Thu, 26 Apr 2007 23:33:32 +0530 "Amit K. Arora" <[EMAIL PROTECTED]>
> > > wrote:
On Thu, May 03, 2007 at 11:28:15PM -0700, Andrew Morton wrote:
> > > The posix spec implies that negative `len' is permitted - presumably
> > > "allocate
> > > ahead of `offset'". How peculiar.
> >
> > I just checked the man page for posix_fallocate() and it says:
> >
> > EINVAL offset
On Fri, 4 May 2007 16:07:31 +1000 David Chinner <[EMAIL PROTECTED]> wrote:
> On Thu, May 03, 2007 at 09:29:55PM -0700, Andrew Morton wrote:
> > On Thu, 26 Apr 2007 23:33:32 +0530 "Amit K. Arora" <[EMAIL PROTECTED]>
> > wrote:
> >
> > > This patch implements the fallocate() system call and adds
On Thu, May 03, 2007 at 09:29:55PM -0700, Andrew Morton wrote:
> On Thu, 26 Apr 2007 23:33:32 +0530 "Amit K. Arora" <[EMAIL PROTECTED]> wrote:
>
> > This patch implements the fallocate() system call and adds support for
> > i386, x86_64 and powerpc.
> >
> > ...
> > +{
> > + struct file *file;
On Thu, May 03, 2007 at 09:29:55PM -0700, Andrew Morton wrote:
On Thu, 26 Apr 2007 23:33:32 +0530 Amit K. Arora [EMAIL PROTECTED] wrote:
This patch implements the fallocate() system call and adds support for
i386, x86_64 and powerpc.
...
+{
+ struct file *file;
+ struct inode
On Fri, 4 May 2007 16:07:31 +1000 David Chinner [EMAIL PROTECTED] wrote:
On Thu, May 03, 2007 at 09:29:55PM -0700, Andrew Morton wrote:
On Thu, 26 Apr 2007 23:33:32 +0530 Amit K. Arora [EMAIL PROTECTED]
wrote:
This patch implements the fallocate() system call and adds support for
On Thu, May 03, 2007 at 11:28:15PM -0700, Andrew Morton wrote:
The posix spec implies that negative `len' is permitted - presumably
allocate
ahead of `offset'. How peculiar.
I just checked the man page for posix_fallocate() and it says:
EINVAL offset or len was less
On Thu, May 03, 2007 at 11:28:15PM -0700, Andrew Morton wrote:
On Fri, 4 May 2007 16:07:31 +1000 David Chinner [EMAIL PROTECTED] wrote:
On Thu, May 03, 2007 at 09:29:55PM -0700, Andrew Morton wrote:
On Thu, 26 Apr 2007 23:33:32 +0530 Amit K. Arora [EMAIL PROTECTED]
wrote:
This
Andrew Morton writes:
> On Thu, 26 Apr 2007 23:33:32 +0530 "Amit K. Arora" <[EMAIL PROTECTED]> wrote:
>
> > This patch implements the fallocate() system call and adds support for
> > i386, x86_64 and powerpc.
> >
> > ...
> >
> > +asmlinkage long sys_fallocate(int fd, int mode, loff_t offset,
On Thu, 3 May 2007 21:29:55 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote:
> > + ret = -EFBIG;
> > + if (offset + len > inode->i_sb->s_maxbytes)
> > + goto out_fput;
>
> This code does handle offset+len going negative, but only by accident, I
> suspect.
But it doesn't handle
On Thu, 26 Apr 2007 23:33:32 +0530 "Amit K. Arora" <[EMAIL PROTECTED]> wrote:
> This patch implements the fallocate() system call and adds support for
> i386, x86_64 and powerpc.
>
> ...
>
> +asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t len)
Please add a comment over
On Thu, 26 Apr 2007 23:33:32 +0530 Amit K. Arora [EMAIL PROTECTED] wrote:
This patch implements the fallocate() system call and adds support for
i386, x86_64 and powerpc.
...
+asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t len)
Please add a comment over this
On Thu, 3 May 2007 21:29:55 -0700 Andrew Morton [EMAIL PROTECTED] wrote:
+ ret = -EFBIG;
+ if (offset + len inode-i_sb-s_maxbytes)
+ goto out_fput;
This code does handle offset+len going negative, but only by accident, I
suspect.
But it doesn't handle offset+len wrapping
Andrew Morton writes:
On Thu, 26 Apr 2007 23:33:32 +0530 Amit K. Arora [EMAIL PROTECTED] wrote:
This patch implements the fallocate() system call and adds support for
i386, x86_64 and powerpc.
...
+asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t len)
This patch implements the fallocate() system call and adds support for
i386, x86_64 and powerpc.
NOTE: It is based on 2.6.21 kernel version.
Signed-off-by: Amit Arora <[EMAIL PROTECTED]>
---
arch/i386/kernel/syscall_table.S |1
arch/powerpc/kernel/sys_ppc32.c |7 ++
This patch implements the fallocate() system call and adds support for
i386, x86_64 and powerpc.
NOTE: It is based on 2.6.21 kernel version.
Signed-off-by: Amit Arora [EMAIL PROTECTED]
---
arch/i386/kernel/syscall_table.S |1
arch/powerpc/kernel/sys_ppc32.c |7 ++
64 matches
Mail list logo
