TODO

   1 Need to process the bad block inode *before* doing the inode scan.
   2
   3 Also check to see if the first block of the inode table is not on the
   4 bad block scan, and fix that.  We need to check for an inaccurate
   5 blocks, and fix them before we start doing anything else with the
   6 filesystem!
   7
   8 ---------------------------------------------------
   9 User request:
  10
  11 BTW: Could you please add some sort of deleted and possibly corrupted file
  12      and inode list to e2fsck report. There should be filenames deleted
  13      from directory inodes, files with duplicate blocks e.t.c.
  14      It's pretty annoying to filter this information from e2fsck output
  15      by hand :-
  16
  17 ------------------------------------------
  18
  19 Add a "answer Yes always to this class of question" response.
  20
  21 ----------------------------------
  22
  23 ext2fs_flush() should return a different error message for primary
  24 versus backup superblock flushing, so that mke2fs can print an
  25 appropriate error message.
  26
  27 ---------------------------------
  28 Date: Mon, 08 Mar 1999 21:46:14 +0100
  29 From: Sergio Polini <s.polini@mclink.it>
  30
  31
  32 I'm reading the sorce code of e2fsck 1.14.
  33 In pass2.c, lines 352-357, I read:
  34
  35 if ((dirent->name_len & 0xFF) > EXT2_NAME_LEN) {
  36         if (fix_problem(ctx, PR_2_FILENAME_LONG, &cd->pctx)) {
  37                 dirent->name_len = EXT2_NAME_LEN;
  38                 dir_modified++;
  39         }
  40 }
  41
  42 I think that I'll never see any messages about too long filenames,
  43 because "whatever & 0xFF" can never be "> 0xFF".
  44 Am I wrong?
  45 --------------------------------------
  46
  47 Add chmod command to debugfs.
  48
  49 ------------------------------------------
  50
  51 Date: Tue, 18 Jan 2000 17:54:53 -0800 (PST)
  52 From: Alan Blanchard <alan@abraxas.to>
  53 To: tytso@MIT.EDU
  54 Subject: DEBUGFS - thanks and a feature idea
  55 Content-Type: TEXT/PLAIN; charset=US-ASCII
  56
  57 Theodore:
  58
  59 First, let me thank you for writing debugfs. Recently, my Linux box
  60 (RH 6.0, 400 MHz PIII, on a DSL line) was hacked into.  The intruder did
  61 an "rm -Rf" on a 34 GB drive with about 5GB of data on it.  I was able to
  62 restore essentially the entire thing with debugfs and a bit of C code and Perl.
  63 Actually, I could have done the entire thing with debugfs and Perl, but I
  64 thought it would be too slow.
  65
  66 During this exercise, I noticed that one small feature was lacking that would
  67 have made my job a bit easier.  The length of a deleted directory is
  68 reported as 0, hence debugfs won't dump the contents of the directory to a
  69 file using the "dump" command.  The only thing that saved me was that the
  70 list of disk blocks is not zeroed out.  I was able to dump the contents of the
  71 directories by using debugfs to get the relevant block numbers, then
  72 using dd to get the actual data.
  73
  74 If debugfs had a feature where it ignored the size of a directory reported by
  75 the inode and instead just dumped all the blocks, it would have facilited
  76 things a bit. This seems like a very easy feature to add.
  77
  78 Again, thanks for writing debugfs (and all the other Linux stuff you've written!).
  79
  80 Cheers,
  81 Alan Blanchard
  82 alan@abraxas.to
  83
  84
  85 -------------------------------------------------------------------
  86
  87 Date: Fri, 21 Jan 2000 14:07:12 -0800
  88 From: "H. Peter Anvin" <hpa@www.transmeta.com>
  89 Subject: mkfs -cc and fsck -c
  90
  91 b) An option to mkfs to zero the partition.  Yes, it can be done with
  92 dd, but it would be a nicer way of doing it.
  93
  94 ------------------------------------------------------------------
  95
  96 Add support for in ext2fs_block_iterate() for a returning the
  97 compressed flag blocks to block_iterate.  Change default to not return
  98 EXT2_COMPRESSED_BLKADDR.  Change e2fsck to pass this flag in.
  99
 100 (The old compression patches did this by default all the time, which
 101 is bad, since it meant e2fsck never saw the EXT2_COMPRESSED_BLKADDR
 102 flagword.
 103
 104 ------------------------------------------------------------
 105
 106 E2fsck should offer to clear all the blocks in an indirect block, not
 107 the entire inode, so there's better recovery for when an indirect
 108 block gets trashed.
 109
 110
 111 -------------------------------------------------------------
 112
 113 From: Yann Dirson - LOGATIQUE <Yann.Dirson@France.Sun.COM>
 114 Date: Thu, 2 Mar 2000 13:52:13 +0100 (MET)
 115
 116 During my experiments on the broken system, I noticed the following in
 117 the badblocks program (which I'm aware is not designed for IDE drives)
 118 - I'd probably have already fixed them if my home system was up :(
 119
 120 * the syntax summary documents 2nd arg as blocks_count, which should
 121 probably read something like end_count.
 122
 123 * testing past end of device is not detected, and lists those blocks
 124 as bad, whereas they simply do not exist.
 125
 126
 127 I think I'll probably add a "max count" option to findsuper(8), so
 128 that I do not have to wait for the whole disk to be scanned when the
 129 system had to be launched with "init=/bin/sh", in which case Ctrl-[CZ]
 130 and friends appear to be absolutely ignored.
 131
 132
 133 Somewhat unrelated, I just noticed the
 134 http://web.mit.edu/tytso/www/linux/ext2.html could be updated:
 135
 136 - could mention SGI xfs (http://oss.sgi.com/projects/xfs/ - they just
 137   release 0.03 snapshot)
 138
 139 ----------------------------------------------------------------
 140
 141 Return-Path: <tytso@MIT.EDU>
 142 Date: Thu, 10 Feb 2000 13:20:14 -0500
 143 From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
 144 To: R.E.Wolff@BitWizard.nl
 145 In-Reply-To: Rogier Wolff's message of Thu, 10 Feb 2000 08:46:30 +0100 (MET),
 146         <200002100746.IAA24573@cave.bitwizard.nl>
 147 Subject: Re: e2fsck request for enhancement.
 148 Phone: (781) 391-3464
 149
 150    Date: Thu, 10 Feb 2000 08:46:30 +0100 (MET)
 151    From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
 152
 153    Lately, while trying to recover a broken disk, my system froze (twice,
 154    until I tried something else) while copying the disk.
 155
 156    So I had a file of about 50Mb that was growing frantically at the
 157    moment of the crash.
 158
 159    e2fsck, then finds an indirect block that is completely bogus. It
 160    starts by asking me if it's ok to clear a few of the referenced
 161    blocks. I say yes. Then it comes to the conclusion:
 162
 163       too many invalid blocks. Clear inode?
 164
 165    and then I get the option to delete the whole file. Not to truncate
 166    the file to a "working" size.
 167
 168
 169    I'd MUCH rather have e2fsck say something like:
 170
 171       inode 1234 references an invalid block 134345454. Hmm.
 172       inode 1234 references 567 out of 50176 invalid blocks,
 173                           all near the end. Truncate file to 49152 blocks?
 174
 175    Here you can see that of the 1024 blocks near the end of the file,
 176    only 567 were detected as invalid. However now 48Mb of the file will
 177    be recovered, instead of thrown away.
 178
 179 That's a good point.  Actually, the right thing is for e2fsck to offer
 180 to clear all of the bad blocks in a particular indirect block.  I don't
 181 know how hard it would be to do that, but I'll put it on my e2fsprogs
 182 TODO list.
 183
 184                                                         - Ted
 185
 186 ---------------------------------------------------------------
 187 From e2fsprogs Debian TODO file as of 1.10-13.
 188
 189 * Maybe make -dbg packages. Look at how others do it.
 190
 191 ---------------------------------------------------------------
 192
 193 Add --lba option to debian icheck command, and have ways of making it
 194 easier to translate LBA to filesystem block numbers.
 195
 196 -------------------------------------------------------
 197
 198
 199
 200 List of projects for e2fsprogs:
 201
 202
 203 1) Make debugfs's "ncheck <inode>" command list all of the pathnames
 204 to an inode, not just only the first link to the inode which is found.
 205 (A good "intro to libext2fs programming interfaces project)
 206
 207         Difficulty: Low         Priority: Low
 208
 209 2) Use a code coverage tool such as Rational's PureCoverage to see
 210 what kind of code coverage we have for e2fsck, and try to add test
 211 cases to increase the code coverage for e2fsck.
 212
 213         Difficulty: Medium      Priorty: Low
 214
 215 3) Use a code coverage tool such as Rational's PureCoverage to see
 216 what kind of code coverage we have for resize2fs, and try to add test
 217 cases to increase the code coverage for resize2fs.
 218
 219         Difficulty: Medium      Priorty: Medium
 220
 221 4) Create a new I/O manager (i.e., test_io.c, unix_io.c, et.al.) which
 222 layers on top of an existing I/O manager which provides copy-on-write
 223 functionality.  This COW I/O manager takes will take two open I/O
 224 managers, call them "base" and "changed".  The "base" I/O manager is
 225 opened read/only, so any changes are written instead to the "changed"
 226 I/O manager, in a compact, non-sparse format containing the intended
 227 modification to the "base" filesystem.
 228
 229 This will allow resize2fs to figure out what changes need to made to
 230 extend a filesystem, or expand the size of inodes in the inode table,
 231 and the changes can be pushed the filesystem in one fell swoop.  (If
 232 the system crashes; the program which runs the "changed" file can be
 233 re-run, much like a journal replay.  My assumption is that the COW
 234 file will contain the filesystem UUID in a the COW superblock, and the
 235 COW file will be stored in some place such as /var/state/e2fsprogs,
 236 with an init.d file to automate the replay so we can recover cleanly
 237 from a crash during the resize2fs process.)
 238
 239         Difficulty: Medium      Priority: Medium
 240
 241 5) Create a new I/O manager (i.e., test_io.c, unix_io.c, et.al.) which
 242 layers on top of an existing I/O manager which provides an "undo"
 243 functionality.  This undo I/O manager takes will take two open I/O
 244 managers, call them "base" and "undo".  The "base" I/O manager is be
 245 opened read/write, and when any writes are sent to the I/O manager,
 246 the I/O manager will check the "undo" I/O manager, using a file format
 247 identical to the one found in (5) above.
 248
 249 This is useful for allowing e2fsck to create an "undo" file, which
 250 would make things like "e2fsck -y" much safer.
 251
 252         Difficulty: Low (once 5 is done)  Priority: Low
 253
 254 6) Modify resize2fs so that it can relocate and reorganize the
 255 filesystem in the following ways: (1) increase the inode size, so that
 256 an existing filesystem can use the EA-in-inode kernel patch, (2)
 257 reserve blocks in the resize inode to allow for on-line resizing.  Use
 258 the COW I/O manager described in (5) in order to provide robustness in
 259 case of a crash during the resize/reorganization operation.
 260
 261         Difficulty: High        Priority: Medium
 262
 263 7) Review the EA-in-inode patches to e2fsck for correctness/code
 264 cleanliness.  (I will probably have to do this myself -- Ted)
 265
 266         Difficulty: High        Priorty: Medium
 267
 268 8) Add support for extent maps to e2fsprogs.  I need to review the
 269 extent maps first/in parallel.
 270
 271         Difficulty: High        Priority: Medium
 272
 273 ----------------------------------
 274
 275 Need to deal with the case where the resize inode overlaps with the
 276 bad blocks inode.
 277