> russ posted some notes how how much memory and disk bandwidth are > required to write at a constant b/w of Xmb/s to venti. venti requires > enormous resources to perform this capability.
Maybe, I was talking generally about the concept of content-addressable storage, not venti in particular. I believe it's possible to do CAS without a major performance hit, look at ZFS, for example. > one thing to note is that we're silently comparing block (ish) storage (venti) > to file systems. this isn't really a useful comparison. i don't know of many > folks who store big disk images on file systems. But many want to back up these images somewhere, and venti makes a good candidate. In my experience, a machine serving iSCSI or AoE to VMs running on different machines is pretty common, and iSCSI or AoE is often done in software, sometimes using big files on a local file system. I don't know any other way to do it in Linux, if you export block storage directly, you lose a lot of flexibility. On Solaris, ZFS takes a different approach, you can ask ZFS to give you a virtual LUN bypassing the VFS completely. >> I'm of a completely different opinion regarding fragmentation. On >> SSDs, it's a non issue. > > that's not correct. a very good ssd will do only about 10,000 r/w random > iops. (certainly they show better numbers for the easy case of compressable > 100% write work loads.) that's less than 40mb/s. on the other hand, a good > ssd will do > about 10x, if eading sequentially. Sure, but 1,000 iops gives you only a 10% performance hit. With rotating rust 10 iops give you the same 10% hit, two orders of magnitude difference. In my experience, even if you are ignoring the fragmentation issue completely, your files will be less than 100 times more fragmented compared with a traditional filesystem so your system overall will be less affected by fragmentation. -- Aram Hăvărneanu
