From: Kent Overstreet <kent.overstreet@gmail.com>
To: "Marcin Mirosław" <marcin@mejor.pl>
Cc: linux-bcache@vger.kernel.org
Subject: Re: Error after filling up fileystem (resend to correct email)
Date: Tue, 29 Mar 2016 03:17:47 -0800 [thread overview]
Message-ID: <20160329111747.GA11536@kmo-pixel> (raw)
In-Reply-To: <56FA5BD7.1060405@mejor.pl>
On Tue, Mar 29, 2016 at 12:41:27PM +0200, Marcin Mirosław wrote:
> Hi!
>
> Because I don't know what features should work I think it's better to
> report a bug than do nothing.
> I created fs, mounted, then I changed compression (via sysfs) to lz4.
> Next I copied portage tree to filesystem. Then I started to think why
> "compression_stats" shows that data are compressed but `df` shows values
> that looks like data are uncompressed:
> cat compression_stats
> uncompressed data:
> nr extents: 1976
> size (bytes): 1784832
> compressed data:
> nr extents: 282264
> compressed size (bytes): 346365952
> uncompressed size (bytes): 6398948352
Yeah, I don't have the code yet to distinguish between compressed/uncompressed
size in the various usage stuff. It's coming.
> df -h:
> Filesystem Size Used Avail Use% Mounted on
> /dev/mapper/system10-bcacheportage 4.0G 4.0G 82M 99% /usr/portage
>
> So I started to create file filled with zeroes: `dd if=/dev/zero
> of=/path/file bs=1M". I filled up filesystem. Then I run `emerge` and I
> got I/O error. In dmesg I see:
>
> [ 4466.898819] kworker/u8:0: page allocation failure: order:4,
> mode:0x2404000
The lz4 code is unfinished - as you can see it doesn't gracefully handle memory
allocation failures yet. The gzip compression code does handle allocation
failures, but won't get as good a compression ratio (because it's doing the
compression in smaller chunks).
At some point I need to dig into the lz4 code and come up with a version that
doesn't require contiguous buffers, but that's going to be difficult.
> Accesing this file with zeroes throws I/O error, it looks that other
> files are accesible. After removing this file with zeroes free space is
> not returned.
Odd.. probably something to do with how the pagecache handles IO errors, I'm
guessing.
You should have been able to still read the data later (after clearing the error
in the pagecache somehow, a drop_caches might do it).
I'll bump the lz4 stuff higher up on the list, I want to use it myself.
next prev parent reply other threads:[~2016-03-29 11:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-29 10:41 Error after filling up fileystem (resend to correct email) Marcin Mirosław
2016-03-29 11:17 ` Kent Overstreet [this message]
2016-03-29 12:38 ` Marcin Mirosław
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=20160329111747.GA11536@kmo-pixel \
--to=kent.overstreet@gmail.com \
--cc=linux-bcache@vger.kernel.org \
--cc=marcin@mejor.pl \
/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.