From: Eric Sandeen <sandeen@sandeen.net>
To: Jeremy Allison <jra@samba.org>
Cc: "Ted Ts'o" <tytso@mit.edu>, "Pádraig Brady" <P@draigbrady.com>,
"Dave Chinner" <david@fromorbit.com>,
"Christoph Hellwig" <hch@infradead.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: fallocate vs ENOSPC
Date: Tue, 29 Nov 2011 17:19:44 -0600 [thread overview]
Message-ID: <4ED56890.60508@sandeen.net> (raw)
In-Reply-To: <20111129230437.GA3241@samba2>
On 11/29/11 5:04 PM, Jeremy Allison wrote:
> On Tue, Nov 29, 2011 at 04:39:08PM -0600, Eric Sandeen wrote:
>> On 11/28/11 2:49 PM, Jeremy Allison wrote:
>>> On Mon, Nov 28, 2011 at 03:29:34PM -0500, Ted Ts'o wrote:
>>>> On Mon, Nov 28, 2011 at 02:51:14PM +0000, Pádraig Brady wrote:
>>>>> It would be better to indicate ENOSPC _before_ copying a (potentially large)
>>>>> file to a (potentially slow) device. If the implementation complexity
>>>>> and side effects of doing this are sufficiently small, then it's worth
>>>>> doing. These discussions are to quantify the side effects.
>>>>
>>>> In that case, why not use statfs(2) as a first class approximation?
>>>> You won't know for user how much fs metadata will be required, but for
>>>> the common case where someone trying to fit 10 pounds of horse manure
>>>> in a 5 pound bag, that can be caught very readily without needing to
>>>> use fallocate(2).
>>>
>>> Yeah, we do that too, if the fallocate call fails.
>>
>> That seems backwards to me; if fallocate fails, statfs(2) isn't going
>> to reveal more space, is it? (modulo metadata issues, anyway?)
>
> It might if fallocate fails with ENOSYS :-).
Doh. Sorry, was not thinking of that failure. :)
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-11-29 23:19 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-25 10:26 fallocate vs ENOSPC Pádraig Brady
2011-11-25 10:40 ` Christoph Hellwig
2011-11-27 3:14 ` Ted Ts'o
2011-11-27 23:43 ` Dave Chinner
2011-11-28 0:13 ` Pádraig Brady
2011-11-28 3:51 ` Dave Chinner
2011-11-28 0:40 ` Theodore Tso
2011-11-28 5:10 ` Dave Chinner
2011-11-28 8:55 ` Pádraig Brady
2011-11-28 10:41 ` tao.peng
2011-11-28 12:02 ` Pádraig Brady
2011-11-28 14:36 ` Theodore Tso
2011-11-28 14:51 ` Pádraig Brady
2011-11-28 20:29 ` Ted Ts'o
2011-11-28 20:49 ` Jeremy Allison
2011-11-29 22:39 ` Eric Sandeen
2011-11-29 23:04 ` Jeremy Allison
2011-11-29 23:19 ` Eric Sandeen [this message]
2011-11-28 18:49 ` Jeremy Allison
2011-11-29 0:26 ` Dave Chinner
2011-11-29 0:45 ` Jeremy Allison
2011-11-29 0:24 ` Dave Chinner
2011-11-29 14:11 ` Pádraig Brady
2011-11-29 23:37 ` Dave Chinner
2011-11-30 9:28 ` Pádraig Brady
2011-11-30 15:32 ` Ted Ts'o
2011-11-30 16:11 ` Pádraig Brady
2011-11-30 17:01 ` Ted Ts'o
2011-11-30 23:39 ` Dave Chinner
2011-12-01 0:11 ` Pádraig Brady
2011-12-07 11:42 ` Pádraig Brady
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ED56890.60508@sandeen.net \
--to=sandeen@sandeen.net \
--cc=P@draigbrady.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=jra@samba.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.