lkml.org 
[lkml]   [2006]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: ext4 features
    On Sat, Jul 01, 2006 at 06:33:01PM +0200, Thomas Glanzmann wrote:
    > I would like to know which new features are planed to be incorported by
    > ext4. So far I only read about supporting bigger filesystems to fit
    > recent hardware developments. So are there any other big goals for ext4?

    Some of the ideas which have been tossed about include:

    * nanosecond timestamps, and support for time beyond the 2038
    * extents (better performance, faster fsck times)
    * persistent preallocation (valid bit in the extent)
    * larger extended attributes
    * checksums for metadata

    ... but the list of features are not necessarily fixed; if you have a
    great ideas, patches are always appreciated. :-)

    > What I personally would like to see most in ext4 are
    >
    > * checksums for data

    One of the more interesting ways of implementing this is that newer
    disks will be providing a facility (at the SCSI layer, and presumably
    eventually for SATA drives as well) where a checksum and some
    "application" (read: filesystem) data. The way this works, as I
    understand it, is that the OS provides the sector-level checksum as
    part of the write operation, which is then checked by the disk before
    it is written (to catch corruption at the bus level) and written on
    the disk. On a read operation, the checksum is read, and the data
    verified at the disk, as well as being passed back to the OS, so the
    OS can do end-to-end level checksum checking. More interestingly,
    there is space for "applation level" (read: filesystem) tagged data,
    which we could use to store information about the inode # and logical
    block # that a particular data blocks is associated with. This would
    allow for a much better recoverability from the inode table getting
    trashed.

    (Of course, the amount of time it would take to recover such a file
    via this method for future terrabyte and pedabyte filesystems is such
    that restoring from backup tapes is almost always going to be faster.
    So such a scheme would only be used when some Ph.D. student has ten
    years of thesis research on a disk with no backups and then
    accidentally runs mkfs on the wrong partition..... of course, one
    could argue that such a stupid student doesnt *deserve* to get a Ph.D. :-)

    > * and snapshots on filesystem basis

    This requires a filesystem that is designed from the get-go to support
    snapshots. So yes, it's lilely not going to happen for ext4.
    Although, if you have a really clever idea, feel free to post patches
    or a detailed technical proposal for how to achieve such a goal. :-)

    - Ted
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-07-04 20:35    [W:0.022 / U:62.524 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site