On Thu, 26 Apr 2007 23:43:32 +0530 "Amit K. Arora" <aarora@xxxxxxxxxxxxxxxxxx> Please always format multiline comments like this: /* * ext4_can_extents_be_merged should have checked that either * bot
Author: "Amit K. Arora" <aarora@xxxxxxxxxxxxxxxxxx>
Date: Mon, 7 May 2007 17:37:19 +0530
Ok. Ok. Will expand the description. Ok. Will add this in the function description as well. Right. I don't seem to find any suitable error from posix description. Can you please suggest an error code
Isn't the idea that libc will interpret -ENOTTY, or whatever is returned here, and fall back to the current library code to do preallocation? This way, the caller of fallocate() will never see this r
My understanding is that glibc will handle zero-filling of files for filesystems that do not support fallocate(). I _think_ this is to convince glibc to do the zero-filling in userspace, but I'm not
I think the use of ext4_journal_extend() (as Amit has proposed) will help here, but it is not sufficient. Because under some circumstances, a journal_extend() failure could mean that we fail to alloc
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
hrm, spose so. It can be a bit suboptimal from the layout POV. The reservations code will largely save us here, but kernel support might make it a bit better. Totally blowing pagecache could be a pro
No! Reservations code is *critical* here. Without reservations, we get disastrously-bad layout if two processes were running a large fallocate() at the same time. (This is an SMP-only problem, btw: o
There is a bit in the extent structure which indicates that the extent has not been initialized. When reading from a block where the extent is marked as unitialized, ext4 returns zero's, to avoid ret
Actually, the reservations code won't matter, since glibc will fall back to its current behavior, which is it will do the preallocation by explicitly writing zeros to the file. This wlil result in th
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 a
yes, but my point is that the proposed behaviour is really quite bad. We will attempt to allocate the disk space and then we will return failure, having consumed all the disk space and having partial
I agree. There is already a loop in Amit's current's patch to call ext4_ext_get_blocks() thoug. Question is how much credit should ext4 to ask for in each journal_start()? .... I think the calculatio
In this case, since the number of blocks to preallocate (eg. N=10GB) is clear, we could improve the current reservation code, to allow callers explicitly ask for a new window that have the minimum N
I agree your point, that's why I mention it only helped the fragmentation issue but not the ENOSPC case. Not totally useless I think. If only half of the space is preallocated because run out of spac
In ext4 (as in XFS) there is a flag stored in the extent that tells if the extent is initialized or not. Reads from uninitialized extents will return zero-filled data, and writes that don't span the
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. Agr
Checking against the fs free blocks is a good idea, since it will prevent the obvious error case where someone tries to preallocate 10GB when there is only 2GB left. But it won't help if there are mu
Author: "Amit K. Arora" <aarora@xxxxxxxxxxxxxxxxxx>
Date: Tue, 8 May 2007 16:22:47 +0530
You are right. But, we still need to "standardize" (and limit) the error codes which we should return from kernel when we want to fall back on the library implementation. The posix_fallocate() librar