-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm aware of the theory and realize that deleting stuff requires writes. I'm also running on the latest b130 and write stuff to disk in large 128k chunks. The thing I was wondering about is whether there is a mechanism that might lower the I/O scheduling priority of a given process (e.g. lower the priority of the rm command) in a manner similar to CPU scheduling priority. Another solution would be to increase the max size the ZFS write buffer, so that writes would not block.
What I'd specifically like to avoid doing is buffer writes in the recorder process. Besides being complicated to do (the process periodically closes and reopens several output files at specific moments in time and keeping them in sync is a bit hairy), I need the written data to appear in the filesystem very soon after being received from the network. The logic behind this is that this is streaming media data which a user can immediately start playing back while it's being recorded. It's crucial that the user be able to follow the real-time recording with at most a 1-2 second delay (in fact, at the moment I can get down to 1 second behind live TV). If I buffer writes for up to 10 seconds in user-space, other playback processes can fail due to running out of data. Regards, - -- Saso Bob Friesenhahn wrote: > On Wed, 6 Jan 2010, Saso Kiselkov wrote: > >> I've encountered a new problem on the opposite end of my app - the >> write() calls to disk sometimes block for a terribly long time (5-10 >> seconds) when I start deleting stuff on the filesystem where my recorder >> processes are writing. Looking at iostat I can see that the disk load is >> strongly uneven - with a lowered zfs_txg_timeout=1 I get normal writes >> every second, but when I start deleting stuff (e.g. "rm -r *"), huge >> load spikes appear from time to time, even to the level of blocking all >> processes writing to the filesystem and filling up the network input >> buffer and starting to drop packets. >> >> Is there a way that I can increase the write I/O priority, or increase >> the write buffer in ZFS so that write()s won't block? > > Deleting stuff results in many small writes to the pool in order to free > up blocks and update metadata. It is one of the most challenging tasks > that any filesystem will do. > > It seems that most recent development OpenSolaris has added use of a new > scheduling class in order to limit the impact of such "load spikes". I > am eagerly looking forward to being able to use this. > > It is difficult for your application to do much if the network device > driver fails to work, but your application can do some of its own > buffering and use multithreading so that even a long delay can be > handled. Use of the asynchronous write APIs may also help. Writes > should be blocked up to the size of the zfs block (e.g. 128K), and also > aligned to the zfs block if possible. > > Bob > -- > Bob Friesenhahn > bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktFAaQACgkQRO8UcfzpOHDsHwCcC4CeWjmZgfINiVYXuyXKAjZg a24AnA2mXCZMJzcAGlu9w8e81X2duNGI =T7qS -----END PGP SIGNATURE----- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
