As far as I'm concerned, I consider the fact that you can extend the size of the inode and get back old data to be the bug. (it's a data security problem). Also: Storing data in the slack space of files is dangerous because, if someone else extends the same file, you're going to lose your data anyways. Depending on an undocumented mis-feature of a filesystem is a rather unsafe way to make a product. If this is intended for production use, I'd say that you're better off to just bite the bullet and create a real file for persistent strage. <div class="gmail_quote">On Mon, Jul 19, 2010 at 12:39 PM, Ryan O'Neill <<a href="mailto:ryan@bitlackeys.com">ryan@bitlackeys.com</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I have developed a file system, it is a virtual memory file system with persistence -- the persistence essentially works by storing the fs data (from memory) into the slack space of ext3 files (We are working on CentOS 5.3 -- old I know). The following details should be sufficient. I keep the inode size the same so that utilities don't see the hidden data -- it appears do_sync_read which ext3 uses and the function that it uses (such as generic_file_read) do not read past the size of the inode. .....</blockquote></div> -- Stephen Samuel <a href="http://www.bcgreen.com">http://www.bcgreen.com</a> Software, like love, 778-861-7641 grows when you give it away