Duncan <1i5t5.duncan <at> cox.net> writes: > > John Goerzen posted on Tue, 05 Nov 2013 07:42:02 -0600 as excerpted: > > > The filesystem in question involves two 2TB USB hard drives. It is 49% > > full. Data is RAID0, metadata is RAID1. The files stored on it are for > > BackupPC, meaning there are many, many directories and hardlinks. I > > would estimate 30 million inodes in use and many of them have dozens of > > hardlinks to them. > > That's a bit of a problem for btrfs at this point, as you rightly mention.
Hi Duncan, Thank you very much for taking the time to reply. Can you clarify a bit about what sort of problems I might expect to encounter with this sort of setup on btrfs? > > > I thought perhaps converting metadata to raid0 would help. So I > > started a btrfs balance start -mconver=raid0 on it. > > > Kernel 3.10 from Debian wheezy backports on i386. > > There's a known bug with balance on current kernels related to pre- > allocated space (as with the systemd journal or torrent files with some > clients). [snip ] > http://permalink.gmane.org/gmane.comp.file-systems.btrfs/287 I'm almost completely sure that this bug wasn't being hit. The files were streamed back by restore(8), and a few written by BackupPC. I checked the source to both just to make sure, and neither have a call to fallocate. I do not believe there were sparse files on the disk either. I also haven't experienced the csum errors mentioned in the post. Thanks again, -- John -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
