I definitely agree that the behaviour should be specified part of the interface. The current behaviour of both ext4 and XFS is that the successful part of the unallocated extent is left in place when
Yeah, and AFAICT glibc leaves them behind ATM. We can't simply walk the range an remove unwritten extents, as some of them may have been present before the fallocate() call. That makes it extremely d
Author: "Amit K. Arora" <aarora@xxxxxxxxxxxxxxxxxx>
Date: Mon, 2 Jul 2007 17:17:30 +0530
Yes, it does. I would not call it a "leak", since the blocks which got allocated as part of the partial success of the fallocate syscall can be strictly accounted for (i.e. they are assigned to a par
Author: "Amit K. Arora" <aarora@xxxxxxxxxxxxxxxxxx>
Date: Tue, 3 Jul 2007 15:38:48 +0530
We now have two sets of flags - 1) the above three with which I think no one has any issues with, and 2) the ones below, for which we need some discussions before finalizing on them. I will prefer fa
Yes, I do. FA_FL_DEL_DATA is plain stupid, a preallocation call should never delete data. FA_FL_DEALLOC should probably be a separate syscall because it's very different functionality. While we're at
Author: "Amit K. Arora" <aarora@xxxxxxxxxxxxxxxxxx>
Date: Tue, 3 Jul 2007 17:16:50 +0530
Well, if you see the modes proposed using above flags : FA_FL_DEL_DATA is _not_ being used for preallocation. We have two modes for preallocation FA_ALLOCATE and FA_RESV_SPACE, which do not use this
Amit K. Arora wrote: FA_FL_NO_MTIME 0x10 /* keep same mtime (default change on size, data change) */ FA_FL_NO_CTIME 0x20 /* keep same ctime (default change on size, data change) */ NACK to these aswe
Sorry, but this doesn't make any sense. There is no need to put every feature in the XFS ioctls in the syscalls. The XFS ioctls will need to be supported forever anyway - as I suggested before they r
You're not :) You're using an O_INVIBLE equivalent (as described below), which would be a useful thing to have at the VFS level, but adding hacks to some system calls only wouldn't help any HSM syste
Author: "Amit K. Arora" <aarora@xxxxxxxxxxxxxxxxxx>
Date: Thu, 12 Jul 2007 13:56:50 +0530
As you suggest, let us just have two modes for the time being: As the name suggests, when FALLOC_ALLOCATE_KEEP_SIZE mode is passed it will result in file size not being changed even if the preallocat
What does FALLOC_ALLOCATE mean vs. not passing this flag? I have no objection to this as long as the code remains with these as "flags" instead of "modes"... Essentially just dropping the FALLOC_FL_D
I definitely agree that the behaviour should be specified part of the interface. The current behaviour of both ext4 and XFS is that the successful part of the unallocated extent is left in place when
Yeah, and AFAICT glibc leaves them behind ATM. We can't simply walk the range an remove unwritten extents, as some of them may have been present before the fallocate() call. That makes it extremely d
Author: "Amit K. Arora" <aarora@xxxxxxxxxxxxxxxxxx>
Date: Mon, 2 Jul 2007 17:17:30 +0530
Yes, it does. I would not call it a "leak", since the blocks which got allocated as part of the partial success of the fallocate syscall can be strictly accounted for (i.e. they are assigned to a par
Author: "Amit K. Arora" <aarora@xxxxxxxxxxxxxxxxxx>
Date: Tue, 3 Jul 2007 15:38:48 +0530
We now have two sets of flags - 1) the above three with which I think no one has any issues with, and 2) the ones below, for which we need some discussions before finalizing on them. I will prefer fa
Yes, I do. FA_FL_DEL_DATA is plain stupid, a preallocation call should never delete data. FA_FL_DEALLOC should probably be a separate syscall because it's very different functionality. While we're at
Author: "Amit K. Arora" <aarora@xxxxxxxxxxxxxxxxxx>
Date: Tue, 3 Jul 2007 17:16:50 +0530
Well, if you see the modes proposed using above flags : FA_FL_DEL_DATA is _not_ being used for preallocation. We have two modes for preallocation FA_ALLOCATE and FA_RESV_SPACE, which do not use this