Date: Tue, 14 Jan 1997 10:54:57 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: lada@ws2301.gud.siemens.co.at (Hr.Ladavac) Cc: avalon@coombs.anu.edu.au, terry@lambert.org, stesin@gu.net, karpen@ocean.campus.luth.se, hackers@freebsd.org Subject: Re: truss, trace ?? Message-ID: <199701141754.KAA00177@phaeton.artisoft.com> In-Reply-To: <199701141034.AA263998091@ws2301.gud.siemens.co.at> from "Hr.Ladavac" at Jan 14, 97 11:34:50 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. This works, until you realize that you run linearly forward through the log file. I assume you steal space in the inode to store the offset of the first valid block in the file? A log file may very well contain valid NULL data... indistinguishable from a zero-fill block coming from the read of a hole. This does not address log files with internal structure boundries that do not allign to disk block boundries. Like wtmp. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701141754.KAA00177>