Date: Sun, 03 Mar 2013 00:07:14 +0100 From: deeptech71 <deeptech71@gmail.com> To: freebsd-current@freebsd.org Subject: Re: access to hard drives is "blocked" by writes to a flash drive Message-ID: <51328622.10409@gmail.com> In-Reply-To: <42B72A5B-A363-426B-9F6C-7F8B3B7E7543@FreeBSD.org> References: <51323712.5000406@gmail.com> <42B72A5B-A363-426B-9F6C-7F8B3B7E7543@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/02/2013 21:46, Edward Tomasz Napierała wrote: > Wiadomość napisana przez deeptech71 w dniu 2 mar 2013, o godz. 18:29: >> When one of my flash drives is being heavily written to; typically by ``svn update'' on /usr/src, located on the flash drive; the following can be said about filesystem behavior: >> >> - ``svn update'' seems to be able to quickly update a bunch of files, but is then unable to continue for a period of time. This behavior is cyclical, and cycles several times, depending on the amount of updating work to be done for a particular run of ``svn update''. >> - Access to any filesystem, whether on the said flash drive or not, seems to be hindered a lot, typically during the said "unable to continue" time. Reading of a file on a hard drive was once delayed for more than 10 seconds. Seemingly as a consequence, the starting of top(1) is also typically delayed. > > When that happens, could you do "ps axl" and see the WCHAN column > for the affected processes? Is it "wdrain"? What do you mean by "the affected processes"? The MWCHAN of an ``svn update'' contained long "wdrain" periods (but included "getblk", "drainvp", etc.). ``[bufdaemon]'' sometimes seemed to somewhat follow the "wdrain" state of ``svn update''. I've also found out that the inability for top(1) or ps(1) to start immediately has something to do with X -- in the virtual terminals, there was never a delay.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51328622.10409>