On Wed, 25 Sep 2013 12:11:24 +0200 David Sterba <dsterba@xxxxxxx> wrote: > On Mon, Sep 23, 2013 at 01:43:48PM -0400, Josef Bacik wrote: > > I've done that with a patch in bugzilla, hopefully that will fix > > it. I've not had time to try and reproduce myself, but I assume if > > you do something like create a random file, then create 100000 > > snapshots and then defrag it will probably hit the same problem. > > Thanks, > > The patch looks ok. > > I've tried to reproduce it with 100k subvolumes but was not lucky to > hit the allocation failure. For me, it was quite easy (i.e. every few days) to hang the server with 32 GB RAM with the following: - BackupPC running, - fs mounted with noatime,compress-force=zlib - extended inode refs enabled, - skinny metadata extent refs enabled, - qgroups enabled. For those unfamiliar, BackupPC is a backup program. It works by rsyncing data from (possibly many) remote systems. Then, it "deduplicates" identical files, by hardlinking the files to identical ones in its pool. As a result, a system running BackupPC will have lots of files (multiple revisions of backups, from many systems) with lots of hardlinks. Additionally, once per night, BackupPC scans its pool of hardlinked files to find the ones with no hardlinks (meaning, file is unused, can be removed); typically, the process takes many hours to finish. I believe this is when my system with btrfs was hanging. BackupPC doesn't use any specific btrfs features, like snapshots. With the above, my system was hanging regularly, every few days. I've disabled BackupPC and I'm running rsync + btrfs snapshot now - no hang since then (at least till now). Could be coincidence, but who knows. [1] http://backuppc.sourceforge.net -- Tomasz Chmielewski http://wpkg.org -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
