again i say (eventually) some "zfs sendndmp" type of mechanism seems the right
way to go here *shrug*
-=dave
> Date: Mon, 5 Nov 2007 05:54:15 -0800> From: [EMAIL PROTECTED]> To:
> zfs-discuss@opensolaris.org> Subject: Re: [zfs-discuss] HAMMER> > 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
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
