Date: Wed, 15 Jan 1997 13:56:30 +1100 (EST) From: proff@suburbia.net To: terry@lambert.org (Terry Lambert) Cc: hackers@freebsd.org Subject: cyclic file type Message-ID: <19970115025630.25674.qmail@suburbia.net> In-Reply-To: <199701150000.RAA02388@phaeton.artisoft.com> from Terry Lambert at "Jan 14, 97 05:00:14 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > It's quite easy actually. There are two ways: > > > > (a) always truncate by the size of the last write. > > (b) define the cycle period to be a multiple of > > the record size. > > This will work if the record size does not vary. Yes, I'm presuming this. > > This also assumes that you are truncating on character, not block > boundries, or that the structures are some even log2 of the block > size (if you truncate on block boundries). > > Having a file specific truncator that just shifted records down > in the file, on record boundries, would undoubtedly work, but you > would need NULLFS working for you to derive a layer so that you > could hide it happening, at the user level. NULLFS-current is working for me, at least for an anon ftp mount. I think you are looking at this at too low a level. If we mandate that CYCLIC files are not mmapable (which seems a fair presumption), and store a pointer to the current beginning of the file within the cycle region then why not merely modify read, write and lseek to recalculate offsets relative to this pointer? Boundaries are only a little more problematic, requiring two split reads or two split writes to cover the wrap. By "truncate" I wasn't actually referring to literal forward truncation, but the changing of a high-level start-of-cycle pointer, as per a cyclic stack. Cheers, Julian.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970115025630.25674.qmail>