On 06/26/2013 7:54 am, Theodore Ts'o wrote:
On Wed, Jun 26, 2013 at 10:02:05AM -0400, Theodore Ts'o wrote:
In this particular case, we could reflect the error all the way up to
the ftruncate(2) system call. Fixing this is going to be a bit
involved, unfortunately; we'll need to update a fairly large number
of
function signatures, including ext4_truncate(), ext4_ext_truncate(),
ext4_free_blocks(), and a number of others.
One thing that comes to mind. If we change things so that ftruncate
reflects an ENOMEM error all the way up to userspace, one side effect
of this is that the file may be partially truncated when ENOMEM is
returned. Applications may not be prepared for this.
Hi Ted, it's the newbie again. I'd like to throw out a possible
band-aid, which I know is ugly, but I'm not sure how it compares to
other ideas discussed.
What if there was a check at the start of the chain for free memory?
For example:
1. User program calls function_x(parameter y).
2. We know function_x() calls function_a(), function_b(), and
function_c().
3. Based upon our knowledge of those functions (and perhaps
parameter y), we can _estimate_ that function_x() will require
z bytes memory.
4. Alter function_x() so that the first step is to check for free
memory z.
Upside
1. Obvious memory shortages are returned immediately, instead of 30
steps down the chain.
2. No risk of non-deterministic data changes (if caught; see
downside).
2. No risk of infinite loop due to retries.
3. Puts a spotlight on applications that do not correctly handle
ENOMEM, which to me is the equivalent of not correctly calling
fsync().
Downside
1. Does not guarantee that memory will be available when ext4 needs
its. Memory might be available during this pre-check, but another
process might scoop it up between the pre-check and ext4's
allocation.
2. Does not catch all cases. The check is only an estimate.
Thank you for your patience and for answering my questions.
Joseph D. Wagner
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
