Mailinglist Archive: opensuse-kernel (56 mails)

< Previous Next >
Re: [opensuse-kernel] BTRFS bug, 3.3 rc6 ..system screwed up
On Sat, Mar 10, 2012 at 05:54:04PM -0300, Cristian Rodríguez wrote:
On 10/03/12 16:44, Bruno Friedmann wrote:
I've saw exactly the same situation in a vm
/ being full 360Mb free during a zypper dup

There is something really wrong with this stuff..

- All monitoring programs report that there is space available.
- No popup, no warning whatsoever that the filesystem X is becoming
full (probably related to the previous one)
- Subtle random "no space left on device".. usually "fixed" by
running btrfs filesystem balance ... or something absurd like:

The no space message may be temporary, in case when the block
reservation is done and then the file contents get inlined to the tree,
so the previously reserved block is not used. This accounting is done at
transaction commit time, ie. every 30 seconds or when sync is called
(or when backgroud writeback starts to flush pages to disk).

first time : osc build --clean --> delay --> rpm complains about the
db..then no space left on device, no packages installed.

second time: osc build --clean --> setup packages but stops at the
few last ones..

third time --> rm -rf /path/to/the/package/build/root
osc build --> package builds correctly, no errors, system normal can write anything else to the FS.. WTF !!!

During these commands lots of file data are in flight and one simply
cannot know when the blocks are returned back and used for other files,
or just are kept reserved and hits no-space.

This happened a lot in 3.2 kernels, and 3.3 improved the situation,
however with patch

there are reports of early no-space (because of too eager block
reservations). This patch is not in opensuse kernel.

osc build --> some *other* app, like the music player or the browser
crashes.. (!!!!)

Do these application handle ENOSPC return code? :)

To unsubscribe, e-mail: opensuse-kernel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-kernel+owner@xxxxxxxxxxxx

< Previous Next >