FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EXT3 Users

 
 
LinkBack Thread Tools
 
Old 07-19-2010, 07:39 PM
"Ryan O'Neill"
 
Default problem with custom fs that utilizes ext3

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.

When storing this persistent data in the slack space of ext3, I create
something like a journal that contains the names of the ext3 files and
how much data we have in the slack space. So when I remount my file
system, a read_Journal()
happens, and here is the issue --

I temporarily extend the size of the inode of the ext3 file so I can
get at the hidden data, then I put the inode size back. For along time
this returned 0's, I then ( believe this made the change) marked the
inode as dirty
and flushed the page so it forced the change of the inode extension,
because I knew the data was there. Now I get the actual data (using
do_sync_read) -- but it
only works for the first file in the journal (98% of the time).
read_journal() works in
a loop, it reads through each journal entry, and when it tries to
perforrm
the same operation on another ext3 file, after extending the inode it
just gets zeroes back. But I know the data is there, because if I
leave the inode extended, I use 'vi' to open the file and I can see
the data.

Is this some type of page cache issue? How can I get around this? Any
input would be greatly appreciated. Thank you.

I can't really give code slices, but the general idea is

i_size = i_size_read(inode);
i_size += extended_size;
i_size_write(inode, isize);
mark_inode_dirty(ext3_inode);
wakeup_pdflush(0); <- I realize this is an overkill, but I was just
trying to get it to work before I used aops->commit_write on the
actual page of the inode.

ext3_file->f_op->llseek(seek to start of hidden data);
ext3_file->f_op->read(read in the data that is hidden at this location)

The first time I go through this operation it works, I get the data
back into memory and can reconstruct a file in virtual memory
all subsequent attempts fail -- although I believe once or twice it did work.

I simply don't understand the underlying page cache enough I'm
guessing. Any help would be greatly appreciated on this, thank you
all.

Regards, Ryan.

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 08-24-2010, 08:32 PM
Stephen Samuel
 
Default problem with custom fs that utilizes ext3

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

Thread Tools




All times are GMT. The time now is 09:36 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org