X-Git-Url: https://git.whamcloud.com/?a=blobdiff_plain;f=TODO;h=d531d1750bdf59805bed963d8f72f0da660aebad;hb=551ab6d8e0d4c9d3f5745b1e34153e8e9f82621b;hp=360a07e8e611e641dcc192075c69be9e3923b05b;hpb=cc73e0401dad790066440608498f856e62bc2b68;p=tools%2Fe2fsprogs.git diff --git a/TODO b/TODO index 360a07e..d531d17 100644 --- a/TODO +++ b/TODO @@ -1,3 +1,11 @@ +Need to process the bad block inode *before* doing the inode scan. + +Also check to see if the first block of the inode table is not on the +bad block scan, and fix that. We need to check for an inaccurate +blocks, and fix them before we start doing anything else with the +filesystem! + +--------------------------------------------------- User request: BTW: Could you please add some sort of deleted and possibly corrupted file @@ -40,21 +48,6 @@ Add chmod command to debugfs. ------------------------------------------ -fix up get_backup_sb, so that it doesn't choose something bogus if -fs->super->.... is ridiculous - ----------------------------------- - -Maybe a bug in debugfs v.1.14: -if a file has more than one hardlink, only the first filename is shown when -using command - ncheck - ------------------------------------- - -Add a filesystem creation date to the superblock - ------------------------------------ Date: Tue, 18 Jan 2000 17:54:53 -0800 (PST) From: Alan Blanchard To: tytso@MIT.EDU @@ -95,10 +88,6 @@ Date: Fri, 21 Jan 2000 14:07:12 -0800 From: "H. Peter Anvin" Subject: mkfs -cc and fsck -c -a) An option to mkfs to run badblocks in read/write mode. The -filesystem is blank, so this is the perfect time to run the read/write -test. - b) An option to mkfs to zero the partition. Yes, it can be done with dd, but it would be a nicer way of doing it. @@ -144,7 +133,6 @@ and friends appear to be absolutely ignored. Somewhat unrelated, I just noticed the http://web.mit.edu/tytso/www/linux/ext2.html could be updated: -- mentions 1.17 as new :) - could mention SGI xfs (http://oss.sgi.com/projects/xfs/ - they just release 0.03 snapshot) @@ -195,4 +183,95 @@ TODO list. - Ted ----------------------------------------------------------------- +--------------------------------------------------------------- +From e2fsprogs Debian TODO file as of 1.10-13. + +* Maybe make -dbg packages. Look at how others do it. + +--------------------------------------------------------------- + +Add --lba option to debian icheck command, and have ways of making it +easier to translate LBA to filesystem block numbers. + +------------------------------------------------------- + + + +List of projects for e2fsprogs: + + +1) Make debugfs's "ncheck " command list all of the pathnames +to an inode, not just only the first link to the inode which is found. +(A good "intro to libext2fs programming interfaces project) + + Difficulty: Low Priority: Low + +2) Use a code coverage tool such as Rational's PureCoverage to see +what kind of code coverage we have for e2fsck, and try to add test +cases to increase the code coverage for e2fsck. + + Difficulty: Medium Priorty: Low + +3) Use a code coverage tool such as Rational's PureCoverage to see +what kind of code coverage we have for resize2fs, and try to add test +cases to increase the code coverage for resize2fs. + + Difficulty: Medium Priorty: Medium + +4) Create a new I/O manager (i.e., test_io.c, unix_io.c, et.al.) which +layers on top of an existing I/O manager which provides copy-on-write +functionality. This COW I/O manager takes will take two open I/O +managers, call them "base" and "changed". The "base" I/O manager is +opened read/only, so any changes are written instead to the "changed" +I/O manager, in a compact, non-sparse format containing the intended +modification to the "base" filesystem. + +This will allow resize2fs to figure out what changes need to made to +extend a filesystem, or expand the size of inodes in the inode table, +and the changes can be pushed the filesystem in one fell swoop. (If +the system crashes; the program which runs the "changed" file can be +re-run, much like a journal replay. My assumption is that the COW +file will contain the filesystem UUID in a the COW superblock, and the +COW file will be stored in some place such as /var/state/e2fsprogs, +with an init.d file to automate the replay so we can recover cleanly +from a crash during the resize2fs process.) + + Difficulty: Medium Priority: Medium + +5) Create a new I/O manager (i.e., test_io.c, unix_io.c, et.al.) which +layers on top of an existing I/O manager which provides an "undo" +functionality. This undo I/O manager takes will take two open I/O +managers, call them "base" and "undo". The "base" I/O manager is be +opened read/write, and when any writes are sent to the I/O manager, +the I/O manager will check the "undo" I/O manager, using a file format +identical to the one found in (5) above. + +This is useful for allowing e2fsck to create an "undo" file, which +would make things like "e2fsck -y" much safer. + + Difficulty: Low (once 5 is done) Priority: Low + +6) Modify resize2fs so that it can relocate and reorganize the +filesystem in the following ways: (1) increase the inode size, so that +an existing filesystem can use the EA-in-inode kernel patch, (2) +reserve blocks in the resize inode to allow for on-line resizing. Use +the COW I/O manager described in (5) in order to provide robustness in +case of a crash during the resize/reorganization operation. + + Difficulty: High Priority: Medium + +7) Review the EA-in-inode patches to e2fsck for correctness/code +cleanliness. (I will probably have to do this myself -- Ted) + + Difficulty: High Priorty: Medium + +8) Add support for extent maps to e2fsprogs. I need to review the +extent maps first/in parallel. + + Difficulty: High Priority: Medium + +---------------------------------- + +Need to deal with the case where the resize inode overlaps with the +bad blocks inode. +