Re: problem with custom fs that utilizes ext3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <ryan@xxxxxxxxxxxxxx> 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
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users

[Index of Archives]         [Linux RAID]     [Kernel Development]     [Red Hat Install]     [Video 4 Linux]     [Postgresql]     [Fedora]     [Gimp]     [Yosemite News]

  Powered by Linux