On Fri, 27 Sep 2013, James Harper <[email protected]> wrote: > I want to create a filesystem to store my on-disk backups (from Bacula) on > a new server. These backup files will be few (less than 10000) and mostly > huge (>1GB). Because I will have multiple files being written out at once, > a large data per inode ratio seems to make sense as it will greatly reduce > fragmentation, and wasted space would be low because of the small number > of files. Also because the write pattern is exclusively streaming writes, > I can go against my normal rule and use RAID5. > > I've chosen a 4MB of data per inode ratio based on some rough calculations, > but while my mkfs.ext3 <dev> -i 4194304 just raced through initially, when > it got to "Writing superblocks and filesystem accounting information:" it > just seemed to hang. Strace says it's doing seek, write 4k, seek, write > 4k, over and over again. I hit ^C and the process is now [mkfs.ext3], but > the system is still pegged at 100% disk utilisation.
One of the features of Ext4 is uninit_bg which if enabled at mkfs time should reduce creation time. I don't have a convenient large storage device to test this with. > Any suggestions as to how I could make this go faster? The filesystem is > around 8TB (RAID5 of 4 x 3TB disks), so it's not exactly small, and the > disks are only 7200RPM SATA, but I know xfs would complete pretty quick. > I'd use xfs but over the years I've used xfs and ext3 in roughly equal > proportions, and I've lost 3 xfs filesystems and no ext3 filesystems, so > I'm a little reluctant to commit to it. I wouldn't use Ext3 for a device that big. Why can't you use ZFS? I'm using BTRFS for all my backups nowadays so any data corruption will be flagged. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
