Re: Error after filling up fileystem (resend to correct email)

W dniu 29.03.2016 o 13:17, Kent Overstreet pisze:

On Tue, Mar 29, 2016 at 12:41:27PM +0200, Marcin Mirosław wrote:

quoted

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.

Ok, thanks for info.

quoted

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.

quoted

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.

When I did test with filling up free space and I didn't had I/O error
then free space was calculated correctly.

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.

Great! gzip is slow for me (at least used with zfs).

Thanks,
Marcin