Date: Tue, 14 Jan 1997 11:34:50 +0100 (MEZ) From: "Hr.Ladavac" <lada@ws2301.gud.siemens.co.at> To: avalon@coombs.anu.edu.au (Darren Reed) Cc: terry@lambert.org, stesin@gu.net, karpen@ocean.campus.luth.se, hackers@FreeBSD.org Subject: Re: truss, trace ?? Message-ID: <199701141034.AA263998091@ws2301.gud.siemens.co.at> In-Reply-To: <199701140339.TAA00166@freefall.freebsd.org> from "Darren Reed" at Jan 14, 97 02:37:13 pm
next in thread | previous in thread | raw e-mail | index | archive | help
E-mail message from Darren Reed contained: > > The way I see it, there some things to consider which you may (or may > not) want to `work' with cyclic files: > > * offset - when you pass byte n of an n byte cylic file, should lseek tell > you that you're at byte n+1 or 0 ? > > Does it make sense to return n+1 if it can't lseek to that > absolute position ? Would lseek() be hacked to goto position > x as x % n ? > > > * blocks - why do you need to shuffle blocks around ? Why not just just > the offset pointer once you get to the end ? (In effect, the > write is done in 2 parts: first to the end of the file, the > second from the start). > > * readers - if a reader is open and at position y and the next write will > go from x to x+n whre x+n > y does the writer block ? (Consider > that all data from y around to x is valid). There is a rather simple way to satisfy most of these semantic requirements: replace the leading blocks with holes--the file grows in the length, lseek works as expected, but write is only guaranteed to succeed if it fails in the last part of the file, and the filesystem occupancy does not increase. read succeeds always, but sometimes it returns a buffer full of (leading) zeros. > > I guess you're thinking of what happens when you keep appending to a file > ...(open - write - close. I donm't see that non-block sized record > files can exist as cyclic files properly under Unix, eg: > > I have a 30,000 byte cyclic file. I write 1 byte to it, making 30,001. > This isn't enough to delete the first block, but you must append it. > (hmmm, would this mean the first block would be a fragment - would it even > work ?) Don't see a problem here; just blast away the leading blocks--unallocate them. The last block can easily be a fragment. /Marino > > Anyone for O_CYCLIC ? > > Darren >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701141034.AA263998091>