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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM Kernel]     [Linux Filesystem Development]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux