Peter Tribble wrote: > I'm not worried about the compression effect. Where I see problems is > backing up million/tens of millions of files in a single > dataset. Backing up > each file is essentially a random read (and this isn't helped by raidz > which gives you a single disks worth of random read I/O per vdev). I > would love to see better ways of backing up huge numbers of files.
It's worth correcting this point... the RAIDZ behavior you mention only occurs if the read size is not aligned to the dataset's block size. The checksum verifier must read the entire stripe to validate the data, but it does that in parallel across the stripe's vdevs. The whole block is then available for delivery to the application. Although, backing up millions/tens of millions of files in a single backup dataset is a bad idea anyway. The metadata searches will kill you, no matter what backend filesystem is supporting it. "zfs send" is the faster way of backing up huge numbers of files. But you pay the price in restore time. (But that's the normal tradeoff) --Joe _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
