Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\s+0\/5\]\s+fallocate\s+system\s+call\s*$/: 24 ]

Total 24 documents matching your query.

1. Re: [PATCH 0/5] fallocate system call (score: 1)
Author: "Amit K. Arora" <aarora@xxxxxxxxxxxxxxxxxx>
Date: Wed, 2 May 2007 18:23:12 +0530
The patch I posted for ext4 *does* change the filesize after preallocation, if required (i.e. when preallocation is after EOF). I may have to change that, if we decide on not doing this. -- Regards,
/archives/xfs/2007-05/msg00019.html (9,368 bytes)

2. Re: [PATCH 0/5] fallocate system call (score: 1)
Author: Andreas Dilger <adilger@xxxxxxxxxxxxx>
Date: Thu, 3 May 2007 03:34:25 -0700
I think I'd agree - it may be useful to allow preallocation beyond EOF for some kinds of applications (e.g. PVR preallocating live TV in 10 minute segments or something, but not knowing in advance ho
/archives/xfs/2007-05/msg00024.html (10,808 bytes)

3. Re: [PATCH 0/5] fallocate system call (score: 1)
Author: "Amit K. Arora" <aarora@xxxxxxxxxxxxxxxxxx>
Date: Wed, 2 May 2007 18:23:12 +0530
The patch I posted for ext4 *does* change the filesize after preallocation, if required (i.e. when preallocation is after EOF). I may have to change that, if we decide on not doing this. -- Regards,
/archives/xfs/2007-05/msg00354.html (9,368 bytes)

4. Re: [PATCH 0/5] fallocate system call (score: 1)
Author: Andreas Dilger <adilger@xxxxxxxxxxxxx>
Date: Thu, 3 May 2007 03:34:25 -0700
I think I'd agree - it may be useful to allow preallocation beyond EOF for some kinds of applications (e.g. PVR preallocating live TV in 10 minute segments or something, but not knowing in advance ho
/archives/xfs/2007-05/msg00359.html (10,808 bytes)

5. [PATCH 0/5] fallocate system call (score: 1)
Author: "Amit K. Arora" <aarora@xxxxxxxxxxxxxxxxxx>
Date: Thu, 26 Apr 2007 23:20:56 +0530
Based on the discussion, this new patchset uses following as the interface for fallocate() system call: asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t len) It seems that only s
/archives/xfs/2007-04/msg00162.html (13,145 bytes)

6. Re: [PATCH 0/5] fallocate system call (score: 1)
Author: Heiko Carstens <heiko.carstens@xxxxxxxxxx>
Date: Fri, 27 Apr 2007 14:10:03 +0200
After long discussions where at least two possible implementations were suggested that would work on _all_ architectures you chose one which doesn't and causes extra effort. This is not limited to st
/archives/xfs/2007-04/msg00178.html (12,696 bytes)

7. Re: [PATCH 0/5] fallocate system call (score: 1)
Author: Jrn Engel <joern@xxxxxxxxxxxxxxx
Date: Fri, 27 Apr 2007 16:43:28 +0200
I believe the long discussion also showed that every possible implementation has drawbacks. To me this one appeared to be the best of many bad choices. Is this implementation worse than we thought? J
/archives/xfs/2007-04/msg00179.html (11,994 bytes)

8. Re: [PATCH 0/5] fallocate system call (score: 1)
Author: Heiko Carstens <heiko.carstens@xxxxxxxxxx>
Date: Fri, 27 Apr 2007 19:46:13 +0200
If one insists to have fd at first argument, what is wrong with having u32 arguments only? It's not that this syscall comes even close to what can be considered performance critical... It adds usersp
/archives/xfs/2007-04/msg00180.html (12,234 bytes)

9. Re: [PATCH 0/5] fallocate system call (score: 1)
Author: Chris Wedgwood <cw@xxxxxxxx>
Date: Fri, 27 Apr 2007 13:42:07 -0700
Well, I was one of those who objected as it seems *UGLY* to me. Right. I'm not that bothered about it. I would prefer it did use clean 64-bit arguments, but given it's a non-critical syscall I'm don'
/archives/xfs/2007-04/msg00181.html (11,789 bytes)

10. Re: [PATCH 0/5] fallocate system call (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Mon, 30 Apr 2007 10:47:02 +1000
Ok, so now for the hard questions - what are the semantics of FA_ALLOCATE and FA_DEALLOCATE? For FA_ALLOCATE, it's supposed to change the file size if we allocate past EOF, right? What's the return v
/archives/xfs/2007-04/msg00192.html (13,024 bytes)

11. Re: [PATCH 0/5] fallocate system call (score: 1)
Author: Chris Wedgwood <cw@xxxxxxxx>
Date: Sun, 29 Apr 2007 22:25:59 -0700
I would argue no. Use truncate for that. Same as above. Yes. FA_ALLOCATE should be able to allocate past-EOF I would argue.
/archives/xfs/2007-04/msg00196.html (10,947 bytes)

12. Re: [PATCH 0/5] fallocate system call (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Mon, 30 Apr 2007 15:56:32 +1000
I'm going from the ext4 implementation because the semantics have not been documented yet. IIRC, the argument for FA_ALLOCATE changing file size is that posix_fallocate() is supposed to change the fi
/archives/xfs/2007-04/msg00197.html (11,605 bytes)

13. Re: [PATCH 0/5] fallocate system call (score: 1)
Author: Chris Wedgwood <cw@xxxxxxxx>
Date: Sun, 29 Apr 2007 23:01:26 -0700
But it's not posix_fallocate; it's something more generic. glibc can do posix_fallocate using truncate + fallocate. What's wrong with that? That seems very reasonable. How many *real* users are there
/archives/xfs/2007-04/msg00198.html (11,075 bytes)

14. [PATCH 0/5] fallocate system call (score: 1)
Author: "Amit K. Arora" <aarora@xxxxxxxxxxxxxxxxxx>
Date: Thu, 26 Apr 2007 23:20:56 +0530
Based on the discussion, this new patchset uses following as the interface for fallocate() system call: asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t len) It seems that only s
/archives/xfs/2007-04/msg00367.html (13,145 bytes)

15. Re: [PATCH 0/5] fallocate system call (score: 1)
Author: Heiko Carstens <heiko.carstens@xxxxxxxxxx>
Date: Fri, 27 Apr 2007 14:10:03 +0200
After long discussions where at least two possible implementations were suggested that would work on _all_ architectures you chose one which doesn't and causes extra effort. This is not limited to st
/archives/xfs/2007-04/msg00383.html (12,696 bytes)

16. Re: [PATCH 0/5] fallocate system call (score: 1)
Author: Jrn Engel <joern@xxxxxxxxxxxxxxx
Date: Fri, 27 Apr 2007 16:43:28 +0200
I believe the long discussion also showed that every possible implementation has drawbacks. To me this one appeared to be the best of many bad choices. Is this implementation worse than we thought? J
/archives/xfs/2007-04/msg00384.html (11,994 bytes)

17. Re: [PATCH 0/5] fallocate system call (score: 1)
Author: Heiko Carstens <heiko.carstens@xxxxxxxxxx>
Date: Fri, 27 Apr 2007 19:46:13 +0200
If one insists to have fd at first argument, what is wrong with having u32 arguments only? It's not that this syscall comes even close to what can be considered performance critical... It adds usersp
/archives/xfs/2007-04/msg00385.html (12,234 bytes)

18. Re: [PATCH 0/5] fallocate system call (score: 1)
Author: Chris Wedgwood <cw@xxxxxxxx>
Date: Fri, 27 Apr 2007 13:42:07 -0700
Well, I was one of those who objected as it seems *UGLY* to me. Right. I'm not that bothered about it. I would prefer it did use clean 64-bit arguments, but given it's a non-critical syscall I'm don'
/archives/xfs/2007-04/msg00386.html (11,789 bytes)

19. Re: [PATCH 0/5] fallocate system call (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Mon, 30 Apr 2007 10:47:02 +1000
Ok, so now for the hard questions - what are the semantics of FA_ALLOCATE and FA_DEALLOCATE? For FA_ALLOCATE, it's supposed to change the file size if we allocate past EOF, right? What's the return v
/archives/xfs/2007-04/msg00397.html (13,024 bytes)

20. Re: [PATCH 0/5] fallocate system call (score: 1)
Author: Chris Wedgwood <cw@xxxxxxxx>
Date: Sun, 29 Apr 2007 22:25:59 -0700
I would argue no. Use truncate for that. Same as above. Yes. FA_ALLOCATE should be able to allocate past-EOF I would argue.
/archives/xfs/2007-04/msg00401.html (10,947 bytes)


This search system is powered by Namazu