Results 1 to 1 of 1
Enjoy an ad free experience by logging in. Not a member yet? Register.
- Join Date
- Jul 2010
strange issue during filesystem development
When I store the data in the slack space I keep the inode size of the ext3 file the same -- this is because not even the lowest level kernel read functions (such as do_sync_read) will read past the size of the inode -- This prevents any type of program including hexdump from seeing the data that hides in the block space after the file. . So here is the problem --
When getting the encrypted data during my read_journal() routine during mounting of the my file system, I increase the inode size with i_size_write (temporarily of course) so that it extends to the end of where my encrypted data is in the ext3 file that it is hiding, I use i_size_write, then do mark_inode_dirty(), then do even a wakeup_pdflush(0); to flush all pages to make sure the inode change happens. I then use the ext3 lseek and read operations to go to the offset where my encrypted data is at, and about 90% of the time its there, otherwise its all 0's. Additionally if I have more than one file that has its data stored in an ext3 file, it never finds its data in the slack space, its always zero. But I know the data is there because I will sometimes not put the inode size back to its original size, then use vi to open the ext3 file where my dad is hiding and I see the encrypted data there just fine.
My question: After extending the offset of the file temporarily, why can't I read in my encrypted data 100% of the time? This seems to be a page cache issue. At first I thought it was because my change to the inode wasn't flushing, and maybe that's part of it -- but I can only get this to work on one of my files during read_journal() any others can't find anything but zeroes in the extended inode size (Even when the data is there).
I'm not super familiar with the linux page cache but have been reading up on that and file systems. Infact I have a fully functioning RAM file system with encryption, no problem -- but the persistence (this last part) is not solved.