Deutsch

Current Texts Comic Imprint Calendar Search PHP-Classes Container-Wizard main.s21

Categories

Analysing ext2/ext3

As I did not really believe the idiots described in Bad Attitude, I went forth on my quest to understand, analyze and hopefully use the EXT3-Filesystem in the way described.
With proper documentation found on a Japanese Server, along with others, I actually started to understand the structure.

The whole system is laid out in blocks. In the superblock is general information about the file system, which is then followed by block groups. These contain a group descriptor, bitmaps telling which blocks are already used and, what is important for me, the inode tables. The inode tables point to blocks, which will now either contain data (file) or a list of file names (directory). My greatest error was to believe that the filenames would be part of the inode, but from now, it makes sense that they are not; as the filename is variable in length, it would make the inode table inefficient. Without the name in the inode table, the inode table can have fixed length entries without wasting space.

Now to my plan to make a statistic of file space usage on a given filesystem: I think it is worthwile. It certainly would not be worthwile to rebuild the directory tree, as I would have to read the inode table and then jump from directory to directory in order to build the tree, which would be exactly the same effort as building it recursively traversing the outer filesystem structure as such, save for the fact that I'd substitute well tested Kernel code with my own jury-rig approach (written in a script language).

BUT: actually, I don't need the directory tree, because what I want to get is, say, statistics about how many PDF files are there or the TIFF/user ratio. What I need is a long list with inode, stat-stuff and filename. And I think getting that is indeed feasible: hop in 128 byte increments over the inode table, remember all inodes which point to files and directories, and afterwards iterate over all directories and jump to the respective blocks to get the inode filenames from the directory entries. If this is done in the order of blocks, then it should be FAAAAST, as everything would be read in a strictly linear fashion.

Comments

Please note: comments posted won't be visible immediately, as they will be checked for harmful content.