Louwtjie Burger wrote: > Richard Elling wrote: > > > > > - COW probably makes that conflict worse > > > > > > > > > > This needs to be proven with a reproducible, real-world > workload before it > > makes sense to try to solve it. After all, if we cannot > measure where > > we are, > > how can we prove that we've improved? > > I agree, let's first find a reproducible example where "updates" > negatively impacts large table scans ... one that is rather simple (if > there is one) to reproduce and then work from there.
I'd say it would be possible to define a reproducible workload that demonstrates this using the Filebench tool... I haven't worked with it much (maybe over the holidays I'll be able to do this), but I think a workload like: 1) create a large file (bigger than main memory) on an empty ZFS pool. 2) time a sequential scan of the file 3) random write i/o over say, 50% of the file (either with or without matching blocksize) 4) time a sequential scan of the file The difference between times 2 and 4 are the "penalty" that COW block reordering (which may introduce seemingly-random seeks between "sequential" blocks) imposes on the system. It would be interesting to watch seeksize.d's output during this run too. --Joe _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
