On Sat, 02 Apr 2011 17:37:58 +0800 liubo <liubo2009@xxxxxxxxxxxxxx> 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/linux-btrfs@xxxxxxxxxxxxxxx/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
