You are looking at the HTML representation of the XML format.
HTML is good for debugging, but probably is not suitable for your application.
See complete documentation, or API help for more information.
<?xml version="1.0"?>
    <allpages gapfrom="UpgradeToExt4" />
      <page pageid="1392" ns="0" title="TODO list">
          <rev xml:space="preserve">=== EXT4 TODO list ===

* Better recovery from a bad per-transaction checksum in the journal
** Teach e2fsck to request permission to skip a bad transaction, but to replay subsequent transactions, and then force a full fsck afterwards.  (If we are lucky the subsequent transactions will contain newer versions of the blocks that were skipped when the transaction with the bad checksum was skipped.)
** Add per-block checksums in the journal.

* test journal checksums under power fail conditions so we can turn it on by default

* Lazy inode table initialization code (to speed up mke2fs)
** See;m=125313617916585&amp;w=2

* Add inode checksums in the inode table (another way to speed up mke2fs; also useful for detecting when a disk writes an inode table block to the wrong part of disk)

* Improve on-line resize
** Need a new ioctl that can support adding multiple block groups at a time, so we can lay out new block groups that respects flex_bg.
** Add support for meta_bg resizing, which is needed to support 64-bit block resizing

* SSD Trim support (we should test using OCZ Vertex and Intel X25-M)

* Improve merging of adjacent extents in the extent tree (i.e., both to the left and to the right)
** Investigate better code factorization in all of the places that manipulate the extent tree (ext4_get_blocks, fallocate, direct I/O, uninit-to-init conversion code)

* Defragmentation support
** Audit and clean up existing code
** Add interfaces to control block allocation decisions to kernel (other users for this functionality?  boot speedup, package installation, fancy database code, etc.   This may impact how we design this interface if it becomes more than just an internal defrag interface)
** Make defrag userspace code smart enough to use this to make holistic defrag decisions and be able to defrag free space, not just reduce the number of contiguous extents in a file.

* Patches from Lustre
** MMP  -- Prevent multiple mounts as a last-ditch failsafe when HA management software goes insane when STONITH fails, etc.  (shipping to Lustre Customers)
** Large Extended Attributes (shipping to Lustre Customers)
** flexible storage of new metadata in directories
** journal-guided RAID resync 
** badness inode heuristic for e2fsck

* Better e2image (raw) sparse image support

* Directory truncation on entry removal</rev>
      <page pageid="1388" ns="0" title="Undeletion">
          <rev xml:space="preserve">In the [ FAQ] Andreas Dilger states:

   In order to ensure that ext3 can safely resume an unlink after a crash, it actually zeros out the
   block pointers in the inode, whereas ext2 just marks these blocks as unused in the block bitmaps
   and marks the inode as &quot;deleted&quot; and leaves the block pointers alone.
   Your only hope is to &quot;grep&quot; for parts of your files that have been deleted and hope for the best.

However, several tools exist that try to recover/undelete lost inodes anyway - with varying success:

{| {{prettytable}}
! Name
! Last updated
| [ giis]                    || 2011-03-05
| [ extundelete] || 2010-06-17
| [ Ext3Grep]    || 2010-04-19
| [ ext3rminator] || 2007-01-12
| [ recover] || 2006-09-20
| [] || 2004-05-27
| [ e2salvage]    || 2003-10-08

There are also free (as in beer) recovery tools for the Microsoft Windows operating system that are able to recover data off ext2/3 partitions: 

* [ R-Studio for Linux] (Commercial)
* [ Stellar Phoenix Linux Data Recovery] (Commercial, demo available for download)

&lt;!-- undelete --&gt;</rev>