Modifying the EXT2 Filesystem

Discussion in 'Kernel Questions' started by BSnapZ, May 14, 2015.

  1. BSnapZ

    BSnapZ New Member

    For a project I'm working on, I need to be able to modify the EXT2 filesystem. I have done extensive research, but as this is not a commonly required task, there seems to be very little helpful information available online. Unfortunately, due to confidentiality, I cannot go into specifics of what I am working on, but I can break the situation down to several key problems that I would be very grateful for assistance on. I should note that I have very little experience with Linux kernel/OS development.

    I realise that this is not an easy problem to tackle, and it is definitely going to be a big challenge seeing as this is only a small part of the project. Any assistance with these problems (or any other warnings/advice) is greatly appreciated.

    If this turns out to be impossible, then the entire project will have to be rethought, hence why I am starting at this point.

    Problem 1: From source code to implementation
    This is not really the first problem, but I need to answer it first in order to make sure I'm on the right track at all! Remember that I am a novice, so this may be a silly question.

    From what I can tell, all EXT2 source code is contained within the kernel source code at linux/fs/ext2/. If I were to modify this source code to make the changes I require, then successfully rebuild the kernel, what would it take to make a drive or partition use this newly modified filesystem? Would I just be able to reformat a drive as EXT2, using the new kernel, and the modified filesystem would be applied to it due to the modified source code? Or am I oversimplifying this?

    Problem 2: Extending the metadata
    A vital part of my project requires me to extend the metadata that each file on the drive contains. In this case, metadata refers to details such as owner, created timestamp, modified timestamp etc. What I would like to be able to do is add and be able to update an additional metadata field. I would think the best approach would be to modify the inode, but after looking through the source code for a long time, I can't see anywhere obvious to start.

    Problem 3: Consequences?
    Assume I am successful in adding and using this field on the modified filesystem. If a file was then moved to another drive, with an unmodified EXT2 filesystem, would the data contained in this extra metadata field be lost? Obviously files are moved between different filesystems all the time with no problem, but I am unsure as to how they handle this. I should note that it is not required to be able to access this metadata on any other system, I only require that the data not be lost.

    Bonus question
    So far I've been using CentOS for my prototype. If there is any advice as to whether this is good/bad/doesn't matter, I would appreciate it.
     
  2. kvandergriff

    kvandergriff New Member

    Search for Extended File Attributes.
     
  3. kelbiiz

    kelbiiz New Member

    This is classic X-Y problem. But as you can't really share details then there's not a lot we can do to help resolve that. It would seems to me that if all your doing is storing metadata then "extended attributes" are you best bet. You do not want to modify the actual file system. If you do then you need to re-write all diagnostic and repair tools as well. If you can "make it work" in the existing file system limitations (again no idea which one is really tripping you up) then you don't have to rewrite tools like fsck. Keep in mind that with a partition ID of ext2 a system tool won't know.
     

Share This Page