On Sat, 8 Aug 2009, Ed Spencer wrote:
On Sat, 2009-08-08 at 09:17, Bob Friesenhahn wrote:
Enterprise storage should work fine without needing to run a tool to
optimize data layout or repair the filesystem. Well designed software
uses an approach which does not unravel through use.
Hmmmm, this is counter to my understanding. I always thought that to
optimize sequential read performance you must store the data according
to how the device will read the data.
That is something I agree in. As a result, the requirement/goal of an
enterprise storage system should be to assure that data is as
contiguious as possible, keeping in mind that mutiple disks (LUNs) may
be involved. It should not unravel and require first-aid in order to
work correctly (like MS-DOS FAT).
If you are using a big LUN on some other storage device, then zfs is
not able to do nearly as much to optimize performance as it would if
it interfaced with a JBOD array. For the big LUN, all it can do is
try to write blocks associated with the current transaction group in
the most contiguious order and read-ahead can not be as useful. With
the big LUN it does not know if the data is on difficult physical
disks so it does not know if reading data in parallel will help reduce
the read latencies.
Maybe my problems will go away once we move into the next generation of
storage devices, SSD's! I'm starting to think that ZFS will really shine
on SSD's.
A SSD slog backed by a SAS 15K JBOD array should perform much better
than a big iSCSI LUN.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
