From: Dave Chinner <david@fromorbit.com>
To: Carlos Maiolino <cmaiolino@redhat.com>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: fallocate behavior during ENOSPC
Date: Thu, 2 Nov 2017 08:04:06 +1100 [thread overview]
Message-ID: <20171101210406.GD4094@dastard> (raw)
In-Reply-To: <20171101125159.p3j2w3h6efu3ciur@hades.localdomain>
On Wed, Nov 01, 2017 at 01:51:59PM +0100, Carlos Maiolino wrote:
> Hi,
>
> Does anyone know how fallocate should behave if it hits an ENOSPC in the middle
> of the block reservation? The man page is not really specific about it.
>
> Being more specific:
>
> If we try to fallocate a 10G file, but the filesystem does not have enough space
> to accommodate the whole allocation request, it will return an ENOSPC, but, it
> doesn't specifically says if the whole allocation should fail or if we can end
> up with a partially allocation.
>
> In the man page:
>
> "After a successful call, subsequent writes into the range specified by offset
> and len are guaranteed not to fail because of lack of disk space."
>
> and:
>
> "ENOSPC There is not enough space left on the device containing the file
> referred to by fd."
>
> By my interpretation, I'd say that if the fallocate fails with -ENOSPC, no
> allocation should be done at all, and the file size should not be changed,
> once we can't guarantee the writes will not fail due lack of disk space.
preallocation can fail half way through, but users can't see that so
there's no real requirement to remove partial allocations on
failure.
Indeed, rollback of partial allocations makes error handling
ridiculously complex - think about an allocation across a range of a
file that has alternating holes and unwritten extents. Half way
through we get ENOSPC, and now we have to go punch out the extents
we've already preallocated. Unless we record every single extent we
allocate in a preallocation, there's no way we can return the file
to it's previous state. We could be allocating thousands of extents
in a single syscall. Hence rollback on failure is pretty much doomed
on all existing filesystems, so it's not required.
> However, what I see is a different behavior for different filesystems, for
> instance, if the file already has some blocks allocated, Ext4 will leave the
> file with a partial pre-allocation made by fallocate,
So will XFS. You just need to fragment freespace or preallocate
over a sparse range with some blocks allocated so that the ENOSPC
occurs on the second+ extent that is allocated in the range given.
> while XFS does not change
> file size of add any extra blocks to the file at all.
Right, XFS will not change the file size unless the preallocation
operation completes successfully.
> If the original file size is 0, it changes a bit, Ext4 will still change the
> file size and leave the partially allocated blocks there, while XFS won't change
> the file size, but will keep the partially pre-allocated blocks.
I think ext4 shouldn't be changing the file size in this case. Write
a fstest to trigger this enospc behaviour and have it fail if the
file size changes on a preallocation that returns ENOSPC....
> I wonder how it should really behave or if it is a filesystem decision?
Should be consistent across all filesystems, hence the fstest...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2017-11-01 21:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-01 12:51 fallocate behavior during ENOSPC Carlos Maiolino
2017-11-01 21:04 ` Dave Chinner [this message]
2017-11-02 15:55 ` Carlos Maiolino
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=20171101210406.GD4094@dastard \
--to=david@fromorbit.com \
--cc=cmaiolino@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).