Nathan Kroenert wrote: > This question triggered some silly questions in my mind: > > Lots of folks are determined that the whole COW to different locations > are a Bad Thing(tm), and in some cases, I guess it might actually be...
There is a lot of speculation about this, but no real data. I've done some experiments on long seeks and didn't see much of a performance difference, but I wasn't using a database workload. Note that the many caches and optimizations in the path between the database and physical medium will make this very difficult to characterize for a general case. Needless to say, you'll get better performance on a device which can handle multiple outstanding I/Os -- avoid PATA disks. > What if ZFS had a pool / filesystem property that caused zfs to do a > journaled, but non-COW update so the data's relative location for > databases is always the same? > > Or - What if it did a double update: One to a staged area, and another > immediately after that to the 'old' data blocks. Still always have > on-disk consistency etc, at a cost of double the I/O's... This is a non-starter. Two I/Os is worse than one. > Of course, both of these would require non-sparse file creation for the > DB etc, but would it be plausible? > > For very read intensive and position sensitive applications, I guess > this sort of capability might make a difference? We are all anxiously awaiting data... -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
