On Fri, Jul 11, 2003 at 11:32:12AM -0500, Eli Carter wrote:
I'm trying to understand what the .truncate method is supposed to do when the file size is extended. (Using 2.5.68-rmk1)
truncate(2) is dark magic and a source of frequent problems.
If I recall, posix doesn't say -what- is supposed to happen with truncate making files larger. It can range from unsupported entirely, to filling with garbage, to filling with zeros, which is what I think linux -likes- to do. However, some filesystems (xfs) have their own methods for acheiving similar goals, and historically haven't always given zero filled pages back, for speed reasons.
In short: i think your filesystem can do whatever it damn well pleases. It might even be configurable. But, relying on any specific behavior in applications is outright wrong...
I hope this helps explain it a bit..
Thanks for replying. :)
fsx (filesystem exerciser) expects a truncated file to be padded with zeros, and that's what I'm trying to do. My problem is that I bread() the skipped blocks, memset their b_data, mark the buffers dirty, and brelse() them... and read()s get the old data from the disk unless I re-mount the fs. I think I need to do something to tell the page cache about the buffer head change, but I can't find what that thing is.
Any pointers?
Eli --------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram eli.carter(a)inet.com `-------------------------------------------------
-- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
