On Mon, 7 May 2007 05:37:54 -0600
Does the proposed implementation handle quotas correctly, btw? Has that
been tested?
It seems to handle quotas fine - the block allocation itself does not
differ from the usual case, just the extents in the tree are marked as
uninitialized...
The only
On Tue, 2007-05-08 at 16:22 +0530, Amit K. Arora wrote:
On Mon, May 07, 2007 at 10:24:37AM -0500, Dave Kleikamp wrote:
On Mon, 2007-05-07 at 17:37 +0530, Amit K. Arora wrote:
On Thu, May 03, 2007 at 09:31:33PM -0700, Andrew Morton wrote:
So we don't implement fallocate on bitmap-based
On May 07, 2007 21:43 -0400, Theodore Tso wrote:
On Mon, May 07, 2007 at 05:15:41PM -0700, Andrew Morton wrote:
Userspace could presumably repair the mess in most situations by truncating
the file back again. The kernel cannot do that because there might be live
data in amongst there.
On Mon, 2007-05-07 at 21:43 -0400, Theodore Tso wrote:
On Mon, May 07, 2007 at 05:41:39PM -0700, Mingming Cao wrote:
We could check the total number of fs free blocks account before
preallocation happens, if there isn't enough space left, there is no
need to bother preallocating.
On Thu, May 03, 2007 at 09:31:33PM -0700, Andrew Morton wrote:
On Thu, 26 Apr 2007 23:43:32 +0530 Amit K. Arora [EMAIL PROTECTED] wrote:
This patch has the ext4 implemtation of fallocate system call.
...
+ /* ext4_can_extents_be_merged should have checked that either
+
On May 03, 2007 21:31 -0700, Andrew Morton wrote:
On Thu, 26 Apr 2007 23:43:32 +0530 Amit K. Arora [EMAIL PROTECTED] wrote:
+ * ext4_fallocate:
+ * preallocate space for a file
+ * mode is for future use, e.g. for unallocating preallocated blocks etc.
+ */
This description is rather
On Mon, 7 May 2007 05:37:54 -0600
Andreas Dilger [EMAIL PROTECTED] wrote:
+ block = offset blkbits;
+ max_blocks = (EXT4_BLOCK_ALIGN(len + offset, blkbits) blkbits)
+ - block;
+ mutex_lock(EXT4_I(inode)-truncate_mutex);
+ credits =
On May 07, 2007 13:58 -0700, Andrew Morton wrote:
Final point: it's fairly disappointing that the present implementation is
ext4-only, and extent-only. I do think we should be aiming at an ext4
bitmap-based implementation and an ext3 implementation.
Actually, this is a non-issue. The reason
On Mon, May 07, 2007 at 03:38:56PM -0700, Andrew Morton wrote:
Actually, this is a non-issue. The reason that it is handled for
extent-only
is that this is the only way to allocate space in the filesystem without
doing the explicit zeroing. For other filesystems (including ext3 and
On Mon, 7 May 2007 19:14:42 -0400
Theodore Tso [EMAIL PROTECTED] wrote:
On Mon, May 07, 2007 at 03:38:56PM -0700, Andrew Morton wrote:
Actually, this is a non-issue. The reason that it is handled for
extent-only
is that this is the only way to allocate space in the filesystem without
On Mon, May 07, 2007 at 07:02:32PM -0400, Jeff Garzik wrote:
Andreas Dilger wrote:
On May 07, 2007 13:58 -0700, Andrew Morton wrote:
Final point: it's fairly disappointing that the present implementation is
ext4-only, and extent-only. I do think we should be aiming at an ext4
bitmap-based
On Mon, 2007-05-07 at 13:58 -0700, Andrew Morton wrote:
On Mon, 7 May 2007 05:37:54 -0600
Andreas Dilger [EMAIL PROTECTED] wrote:
+ block = offset blkbits;
+ max_blocks = (EXT4_BLOCK_ALIGN(len + offset, blkbits)
blkbits)
+- block;
+
On Mon, 07 May 2007 17:00:24 -0700
Mingming Cao [EMAIL PROTECTED] wrote:
+ while (ret = 0 ret max_blocks) {
+ block = block + ret;
+ max_blocks = max_blocks - ret;
+ ret = ext4_ext_get_blocks(handle, inode, block,
+
On Mon, 2007-05-07 at 16:31 -0700, Andrew Morton wrote:
On Mon, 7 May 2007 19:14:42 -0400
Theodore Tso [EMAIL PROTECTED] wrote:
On Mon, May 07, 2007 at 03:38:56PM -0700, Andrew Morton wrote:
Actually, this is a non-issue. The reason that it is handled for
extent-only
is that
On Mon, 2007-05-07 at 17:15 -0700, Andrew Morton wrote:
On Mon, 07 May 2007 17:00:24 -0700
Mingming Cao [EMAIL PROTECTED] wrote:
+ while (ret = 0 ret max_blocks) {
+ block = block + ret;
+ max_blocks = max_blocks - ret;
+ ret =
On May 07, 2007 19:02 -0400, Jeff Garzik wrote:
Andreas Dilger wrote:
Actually, this is a non-issue. The reason that it is handled for
extent-only is that this is the only way to allocate space in the
filesystem without doing the explicit zeroing.
Precisely /how/ do you avoid the zeroing
Andreas Dilger wrote:
My comment was just that the extent doesn't have to be explicitly zero
filled on the disk, by virtue of the fact that the uninitialized flag
will cause reads to return zero.
Agreed, thanks for the clarification.
Jeff
-
To unsubscribe from this list: send the
On Mon, May 07, 2007 at 05:41:39PM -0700, Mingming Cao wrote:
We could check the total number of fs free blocks account before
preallocation happens, if there isn't enough space left, there is no
need to bother preallocating.
Checking against the fs free blocks is a good idea, since it will
On Thu, 26 Apr 2007 23:43:32 +0530 Amit K. Arora [EMAIL PROTECTED] wrote:
This patch has the ext4 implemtation of fallocate system call.
...
+ /* ext4_can_extents_be_merged should have checked that either
+ * both extents are uninitialized, or both aren't. Thus we
19 matches
Mail list logo
