Date: Wed, 13 Dec 2000 20:32:17 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: henrich@sigbus.com (Charles Henrich) Cc: tlambert@primenet.com (Terry Lambert), freebsd-fs@FreeBSD.ORG Subject: Re: Filesystem tuning (minimize seeks) Message-ID: <200012132032.NAA11150@usr08.primenet.com> In-Reply-To: <20001213105434.B24757@sigbus.com> from "Charles Henrich" at Dec 13, 2000 10:54:34 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> > Is this aggregating the output of several seperate machines? > > Yes, my test is running about 25-50 machines writing a 20mb > file to the FreeBSD box. (The clients are FreeBSD as well). > The write is nothing more than a dd. I'm assuming that you want each one of them to append? I don't remember "dd" being able to write an interior region on a file. Is the region you are writing supposed to be appended, and is it at a known offset and of a known size? If so, you could write a program to replace your use of 'dd' that either explicitly opens the file for append each time, or leaves it open, but explicitly seeks to the end of the file. If the order is supposed to be "whoever gets done first", and it's a simple append (i.e. the size is known, but the offset is not known), you will still need to prevent the writes from occurring simultaneously, since there is a ace window between finding the end, and doing the write, and this will mean that you need to pass a token around between, or otherwise synchronize, the writers. FWIW, I can't see the offset being unknown for, for example, a render-farm, since you will want your frames to be in order. Probably the easiest way to do this would be an "I want the token" UDP broadcast, at intervals, with a TCP response by whoever has the token currently. You could implement this in your dd replacement by selecting on the UDP port, the TCP port, and the stdin from which the "dd" would have taken its input. Another way of dealing with this, which won't work on FreeBSD, would be to seek to the end and obtain an advisory lock on the file for the region to be written, writing the last byte with a zero (to extend the file for the next process, so it can get its lock following the region you are hitting; a write is used instead of a truncate, so that concurrent processes don't foul each other up), and then doing the write, and releasing the lock. NFS locking doesn't work on FreeBSD today, so this isn't an option (the fix is pretty trivial -- just grunt work --, but the failure recovery for a server reboot is a pain). In any case, I think "dd" is right out, since it can't handle the necessary inter-node synchronization anyway. > What is the inode state that top displays? It doesn't really display inode state, that I'm aware of, only process state? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012132032.NAA11150>