Selim Daoud wrote: > I was wondering if there were work done in the area of zfs > configuration running out of 100% SSD disks. > > L2ARC and ZIL have been designed as a way to improve long seek > times/latencies of rotational disks. > now if we use only SSD (F5100 or F20) as back end drives for zfs, we > should not need those additional log/cache mechanisms..or at least > algorithms managing those caches might need improvement Given correct tuning ZFS is already pretty solid (pun intended) on SSD. Any log-structured thing is going to be fast on SSD. ZFS has the unique property of being able to mix SSD and traditional SAS/SCSI drives for maximum bang for the buck. If you just want bang, and no buck left, go ahead and buy a zillion SSD drives instead?
If you don't want/need log or cache, disable these? You might want to run your ZIL (slog) on ramdisk. Beware, that without a persisted ZIL there _will_ be dataloss with unexpected shutdowns. I'd go for the default: without explicit log-vdev(s) the ZIL will reside in the storage pool itself. > > in the same way, I guess, when running an OS on a SSD boot disk, > should we still need the same memory swapping mechanisms as we do > today, considering that in that case, the swap device is (nearly) as > fast as memory itself. Is it? I think that when you look up the numbers (for server-grade hardware) you could find an order of magnitude difference. Now there are solid state storage cards that employ RAM chips and backup power to persist the state. These are the fastest in the industry, but I know you will _never_ want to put your multi-terabyte ZFS pools on those (better buy a couple of Ferrari's instead). > To some extension, log journals found in DB would also not be > relevant anymore? > I beg your pardon? The crux with transaction logs is that they get _physically committed_ (and synced, that is) before writing the actual transaction so that the log will survive reboot and the transaction can be rolled back at reboot. This is crucial for atomicity/integrity. So... the log is obviously still required to be on disk/SSD. > > > tia, > > selim > ------------------------------------------------------------------------ > > _______________________________________________ > 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
