From: Eric Sandeen <sandeen@redhat.com>
To: markk@clara.co.uk
Cc: linux-ext4@vger.kernel.org
Subject: Re: fallocate() not "atomic" if insufficient disk space?
Date: Fri, 30 Dec 2011 17:13:53 -0600 [thread overview]
Message-ID: <4EFE45B1.9040902@redhat.com> (raw)
In-Reply-To: <e10c1a3b87ce0766dcc538b8332cb9a4.squirrel@ssl-webmail-vh.clara.net>
On 12/28/11 10:09 AM, markk@clara.co.uk wrote:
> Hi,
>
> I've been experimenting with using fallocate() to pre-allocate space for a
> file on an ext4 partition. I'm testing with Ubuntu kernel
> 3.0.0-14-generic. Does fallocate() behave in the same way on more
> recent/vanilla kernels?
>
> What I expected to happen is that if fallocate() fails due to lack of disk
> space, no space is allocated, i.e. either nothing happens or the
> allocation succeeds.
>
> What actually seems to happen is that all remaining space in the partition
> gets allocated to the file. (Thus risking that other programs will fail
> due to lack of disk space until the file is deleted.)
To be honest, I'm not sure how it is _supposed_ to work, but I see this
same behavior with fallocate, with posix_fallocate calling fallocate, and with
posix_fallocate simply writing out data via glibc, (I tested several of those
combinations on different filesystems, anyway).
Even the posix_fallocate spec doesn't say what is supposed to happen to space
allocated prior to failure, but the implementations seem fairly consistent.
Seems fair to say that callers should check error returns, and unlink or
truncate on error as needed.
-Eric
> If it's relevant, the partition in question has no journal and is mounted
> with barrier=0.
>
> Example on a partition with ~100MB free:
>
> $ fallocate -o 0 -l 999999999 blah
> fallocate: blah: fallocate failed: No space left on device
> $ df /
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/sdb1 3849136 3653604 0 100% /
> $ du blah
> 107860 blah
> $ ls -l blah
> -rw-r--r-- 1 mark mark 110444544 2011-12-28 15:51 blah
> $ rm blah
>
> Same issue when specifying -n to call fallocate() with FALLOC_FL_KEEP_SIZE:
>
> $ fallocate -n -o 0 -l 999999999 blah
> fallocate: blah: fallocate failed: No space left on device
> $ df /
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/sdb1 3849136 3653604 0 100% /
> $ du blah
> 107860 blah
> $ ls -l blah
> -rw-r--r-- 1 mark mark 0 2011-12-28 15:52 blah
>
>
> -- Mark
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" 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-12-30 23:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-28 16:09 fallocate() not "atomic" if insufficient disk space? markk
2011-12-30 23:13 ` Eric Sandeen [this message]
2012-01-04 22:40 ` markk
2012-01-05 0:19 ` Sunil Mushran
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=4EFE45B1.9040902@redhat.com \
--to=sandeen@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=markk@clara.co.uk \
/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.