With regards too http://blogs.sun.com/roch/entry/the_new_zfs_write_throttle
I would have thought that if you had enough data to be written, it is worth just writing it, and not waiting X seconds or trying to adjust things so it only takes 5 seconds
For example different Disk Bus have different data sizes e.g. (If I remember correctly) Fiber Channel packet size 2MB, if you have 2MB you can write to a single disk/lun why not just write it straight away.
If transaction group meta data/log reaches a certain size (say 128k??) why not write the TXG? If transaction group meta data/log is estimated to take more than X ms why not write the TXG? (assume reads are stop while this happens, to prevent large pauses)
if any file has 2MB?? of outstanding data to be written why not do a TXG? and stall the process's write thread until the data is written. ie to prevent "And to avoid the system wide and seconds long throttle effect, the new code will detect when we are dangerously close to that situation (7/8th of the limit) and will **insert 1 tick** delays for applications issuing writes. This prevents a write intensive thread from hogging the available space starving out other threads. This delay should also generally prevent the system wide throttle." A write limit on a individual thread/file would prevent a single file filling up the ARC?
By write/TXG I mean close the existing open TXG, and place it into quiescing, ready for syncing.
So the real question is why wait, why give the system the chance to stall; if you have enough data to write out to disk, that allows the target disk(s) to perform at optimal performance why not write the data out to the disks? (ie decent write I/O size. Even if quiescing state needed to be turned into a small FIFO queue)
Back to the Tennis (Wimbledon) **Cheers _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
