Re: [9fans] fossil pb: FOUND!

[Bakul Shah <bakul@bitblocks.com>]

On Sat, 14 Jan 2012 17:42:12 EST erik quanstrom <quanstro@quanstro.net>  wrote:
> On Sat Jan 14 17:12:49 EST 2012, aram.h@mgk.ro wrote:
> > > content addressed means given the content, you can generate the address.
> > > this is NOT true of zfs at all.
> >
> > How come? With venti, the address is the SHA-1 hash, with ZFS, you get
> > to chose the hash, but it can still be a hash.
>
> because in zfs the hash is not used as an address (lba).

True.

> > My original claim was that fragmentation is a non issue if you have
> > SSDs.  I still claim this and I expanded on the context in my previous
> > post.  Of course that random I/O is slower than sequential I/O, SSD or
> > not, but in practice, filesystem fragmentation causes an amount or
> > random I/O much less than what a SSD can handle, so throughput in the
> > fragmented case is close to the throughput in the sequential case.
> >
> > I don't think that caching is completely irrelevant.  If I have to
> > chose between a complex scheme that avoids fragmentation and a simple
> > caching scheme that renders it irrelevant for a particular workload,
> > I'll chose the caching scheme because it's simpler.
>
> by all means, show us the numbers.  personally, i believe the mfgrs are not
> lying when they say that random i/o yields 1/10th the performance (at best)
> of sequential i/o.


Intel 320 300GB SSD numbers (for example):
seq read:  270MBps
rnd read:  39.5Kiops == 158Mbps @ 4KB
seq write: 205MBps
rnd write: 23.0Kiops == 92MBps  @ 4KB

SSDs don't have to contend with seek times but you have to pay
the erase cost (which can not be hidden in "backround GC" when
you are going full tilt).

For venti you'd pick 8k at least so the write throughput will
be higher that 92MBps (but not double). IIRC ZFS picks a much
larger block size so it suffers less here.

You have to check the numbers using the blocksizes relevant to
you.