Re: problem with custom fs that utilizes ext3

Stephen Samuel <[email protected]>
Newsgroups gmane.comp.file-systems.ext3.user
Message-ID <[email protected]>
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.

On Mon, Jul 19, 2010 at 12:39 PM, Ryan O'Neill <[email protected]> wrote:

> 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.
> .....



-- 
Stephen Samuel http://www.bcgreen.com  Software, like love,
778-861-7641                              grows when you give it away

_______________________________________________
Ext3-users mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/ext3-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.