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

["Marcin Mirosław" <marcin@mejor.pl>]

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:
>> 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.


>> 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.

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