On Sat, 02 Apr 2011 17:37:58 +0800
liubo <[email protected]> wrote:

> On 04/02/2011 05:19 PM, Sergei Trofimovich wrote:
> > The partition is a physical ~5GB --mixed lzo compressed partition.
> > 
> > The kernel 2.6.39-rc1 + reverted commit 
> > c59021f846881a957ac5afe456d0f59d6a517b61.
> > (see http://www.mail-archive.com/[email protected]/msg09083.html)
> > 
> 
> Hi, Sergei,
> 
> I'm digging this...
> 
> Can u show me steps to reproduce this?

I use the filesystem as a storage of large CVS tree and
as temp storage for large compilations, so I can roughly
describe what I did and when it failed.

I've formatter btrfs 5G partition as --mixed and mounter it with lzo compression
on the kernel of version 'v2.6.38-4148-g054cfaa', then checked out there
large CVS tree (~170K files, weights 177MB), copied there linux source (not 
built)
and copied my '/var/'. I ran compiles there and started to get -ENOSPC
OOpses when 'df -h' reported 3.5G free.

As Linus pulled josef's changes, so I've updated to v2.6.38-6555-ga44f99c
and kernel started to OOps right after mount (added assert started to trigger 
earlier).
I've reported it to this ML (link above). josef and sensille helped me to debug 
what's
going wrong [both CCed]. sensille pointed to the commit, which is guilty to 
miscomputing
available space. As I understood they know what exactly screwed up.

The second case (this one):
I still use the same filesystem (didn't reformat, so it might carry some 
corruption
after debugging patches).
I've reverted your change c59021f846881a957ac5afe456d0f59d6a517b61
and made sure it stops OOpsing for me, then updated to 2.6.39-rc1
and reverted only this commit. Filesystem became usable until I've decided
to run large compile on it (clang debug source).

I think at the time of OOps the following things did happen simultaneously:

1. one process was splitting debug symbols of some binary:
  - opened original binary for read
  - write to new file (stripped binary)
  - write debug symbols to separate file

2. another process logged that action to log file

3. the filesystem filled-up and OOpsed. At the time of OOps
   'df -h' showed 200M free.

I'm trying to reproduce this second case ATM (build takes
more, that an hour).

-- 

  Sergei

Attachment: signature.asc
Description: PGP signature

Reply via email to