Moore, Joe writes: > 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. >
But it's not the only thing. The difference between 2 and 4 is the COW penalty that one can hide under prefetching and many spindles. The other thing is to see what is the impact (throughput and response time) of the file scan operation to the ever going random write load. Third is the impact on CPU cycles required to do the filescans. -r > 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 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
