From: "Darrick J. Wong" <djwong@us.ibm.com>
To: cwillu <cwillu@cwillu.com>
Cc: linux-btrfs@vger.kernel.org, linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Premature -ENOSPC on btrfs?
Date: Fri, 29 Apr 2011 17:16:41 -0700 [thread overview]
Message-ID: <20110430001641.GC18929@tux1.beaverton.ibm.com> (raw)
In-Reply-To: <BANLkTimm00fwBukO_C=wS_jK6090rdj2pw@mail.gmail.com>
On Fri, Apr 29, 2011 at 06:00:16PM -0600, cwillu wrote:
> On Fri, Apr 29, 2011 at 5:48 PM, Darrick J. Wong <djwong@us.ibm.com> wrote:
> > Hi,
> >
> > I was giving btrfs (2.6.39-rc4) a quick tryout today and noticed some odd
> > behavior when running a rather stupid test.
> >
> > First, I create a 1GB test fs, format it, and mount it. Then, I run the
> > following command to create a huge file, truncate it, rewrite it, and report
> > what size file got created.
> >
> > # while true; do dd if=/dev/zero of=/mnt/testfile bs=1024k; done
> >
> > This is roughly what I see in terms of file size after filtering out all the
> > "dd: writing `/mnt/testfile': No space left on device" messages.
> >
> > 782237696 bytes (782 MB) copied, 16.5647 s, 47.2 MB/s
> > 545259520 bytes (545 MB) copied, 14.061 s, 38.8 MB/s
> > 780140544 bytes (780 MB) copied, 15.2959 s, 51.0 MB/s
> > 933232640 bytes (933 MB) copied, 15.2241 s, 61.3 MB/s
> > 827326464 bytes (827 MB) copied, 14.8383 s, 55.8 MB/s
> > 931135488 bytes (931 MB) copied, 15.1554 s, 61.4 MB/s
> > 936378368 bytes (936 MB) copied, 2.98301 s, 314 MB/s
> > 393216000 bytes (393 MB) copied, 12.9202 s, 30.4 MB/s
> > 387973120 bytes (388 MB) copied, 13.4906 s, 28.8 MB/s
> > 932184064 bytes (932 MB) copied, 15.3356 s, 60.8 MB/s
> > 785383424 bytes (785 MB) copied, 14.6429 s, 53.6 MB/s
> > 927989760 bytes (928 MB) copied, 15.4386 s, 60.1 MB/s
> > 833617920 bytes (834 MB) copied, 14.6289 s, 57.0 MB/s
> > 936378368 bytes (936 MB) copied, 3.33651 s, 281 MB/s
> > 393216000 bytes (393 MB) copied, 12.9689 s, 30.3 MB/s
> > 389021696 bytes (389 MB) copied, 6.02794 s, 64.5 MB/s
> > 294649856 bytes (295 MB) copied, 1.05144 s, 280 MB/s
> >
> > Strangely, df reports that free space remains, and I can even create a second
> > file to fill the empty space, so clearly the fs isn't full yet. Is this the
> > intended behavior of btrfs? ext4/vfat seem to produce the same size file
> > every time.
>
> https://btrfs.wiki.kernel.org/index.php/FAQ#if_your_device_is_small
>
> You'll want to use mixed block groups with such a small filesystem.
The wiki seems dead, but the Google cache version implies that 2.6.37+ takes
care of enabling mixed block groups already. I also pulled btrfsprogs git and
built a new mkfs, but that didn't seem to solve anything.
--D
next prev parent reply other threads:[~2011-04-30 0:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-29 23:48 Darrick J. Wong
2011-04-30 0:00 ` cwillu
2011-04-30 0:16 ` Darrick J. Wong [this message]
2011-04-30 0:24 ` cwillu
2011-04-30 0:30 ` Darrick J. Wong
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=20110430001641.GC18929@tux1.beaverton.ibm.com \
--to=djwong@us.ibm.com \
--cc=cwillu@cwillu.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@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
all inboxes | Powered by JetHome®