From: Theodore Tso <tytso@mit.edu>
To: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: ext4 features
Date: Mon, 3 Jul 2006 21:02:40 -0400 [thread overview]
Message-ID: <20060704010240.GD6317@thunk.org> (raw)
In-Reply-To: <20060701163301.GB24570@cip.informatik.uni-erlangen.de>
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
next prev parent reply other threads:[~2006-07-04 18:32 UTC|newest]
Thread overview: 126+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-01 16:33 ext4 features Thomas Glanzmann
2006-07-01 17:07 ` Tomasz Torcz
2006-07-01 17:47 ` Thomas Glanzmann
2006-07-01 18:09 ` Claudio Martins
2006-07-01 18:59 ` Thomas Glanzmann
2006-07-01 18:17 ` Tomasz Torcz
2006-07-03 9:44 ` Gabor Gombas
2006-07-03 20:22 ` Helge Hafting
2006-07-03 20:55 ` Tomasz Torcz
2006-07-03 21:01 ` Arjan van de Ven
2006-07-03 21:46 ` Jeff V. Merkey
2006-07-03 21:25 ` Diego Calleja
2006-07-03 22:17 ` Alan Cox
2006-07-04 14:45 ` Jan Engelhardt
2006-07-04 16:35 ` Jeffrey V. Merkey
2006-07-04 18:52 ` Jeff Garzik
2006-07-04 19:40 ` Jeffrey V. Merkey
2006-07-05 13:35 ` Lew Palm
2006-07-03 23:01 ` Jeff V. Merkey
2006-07-04 9:14 ` Benny Amorsen
2006-07-05 4:21 ` Bill Davidsen
2006-07-05 5:13 ` H. Peter Anvin
2006-07-05 5:45 ` Jeffrey V. Merkey
2006-07-07 14:12 ` Pavel Machek
2006-07-05 10:38 ` Krzysztof Halasa
2006-07-07 14:10 ` Pavel Machek
2006-07-07 17:45 ` Krzysztof Halasa
2006-07-07 21:30 ` Pavel Machek
2006-07-08 10:52 ` Krzysztof Halasa
2006-07-08 10:55 ` Pavel Machek
2006-07-08 11:19 ` Krzysztof Halasa
2006-07-08 11:23 ` Pavel Machek
2006-07-08 18:45 ` Avi Kivity
2006-07-08 20:24 ` Krzysztof Halasa
2006-07-04 9:22 ` Petr Tesarik
2006-07-04 11:35 ` Peter Zijlstra
2006-07-04 11:55 ` ext4 features (salvage) Petr Tesarik
[not found] ` <80294dc60607040508l1022d164ybe0ba10858e54f0c@mail.gmail.com>
2006-07-04 12:31 ` Petr Tesarik
2006-07-04 12:42 ` Helge Hafting
2006-07-04 16:20 ` Matthew Frost
2006-07-04 15:25 ` ext4 features Pavel Machek
2006-07-05 4:10 ` Bill Davidsen
2006-07-03 21:46 ` Valdis.Kletnieks
[not found] ` <Pine.LNX.4.61.0607032354170.31747@yvahk01.tjqt.qr>
2006-07-04 14:37 ` Kernel recycler [was: ext4 features] Jan Engelhardt
2006-07-04 11:14 ` ext4 features Krzysztof Halasa
2006-07-04 22:35 ` Frank van Maarseveen
2006-07-04 23:47 ` Claudio Martins
2006-07-03 22:12 ` Alan Cox
2006-07-03 21:59 ` Arjan van de Ven
2006-07-03 23:31 ` ext4 features (checksums) Neil Brown
2006-07-04 1:03 ` Jeff Garzik
2006-07-04 6:09 ` Avi Kivity
2006-07-04 7:02 ` Neil Brown
2006-07-04 8:26 ` Avi Kivity
2006-07-05 11:56 ` Bill Davidsen
2006-07-05 12:06 ` Bill Davidsen
2006-07-05 12:19 ` Avi Kivity
2006-07-08 17:54 ` Bill Davidsen
2006-07-04 8:17 ` Alan Cox
2006-07-04 11:08 ` Thomas Glanzmann
2006-07-04 11:19 ` Krzysztof Halasa
2006-07-04 12:49 ` Helge Hafting
2006-07-05 12:01 ` Bill Davidsen
2006-07-05 12:10 ` Avi Kivity
2006-07-08 18:02 ` Bill Davidsen
2006-07-06 0:36 ` Blatant layering violations (was Re: ext4 features) Valerie Henson
2006-07-06 12:15 ` Xavier Bestel
2006-07-06 17:06 ` Valdis.Kletnieks
2006-07-06 20:02 ` Tom Vier
2006-07-03 21:34 ` ext4 features Bill Davidsen
2006-07-03 21:50 ` Valdis.Kletnieks
2006-07-03 22:04 ` Bruce Ferrell
2006-07-04 14:48 ` Valdis.Kletnieks
2006-07-03 23:00 ` Bill Davidsen
2006-07-04 15:01 ` Valdis.Kletnieks
2006-07-05 2:40 ` Bill Davidsen
2006-07-05 2:47 ` Valdis.Kletnieks
2006-07-04 12:52 ` Helge Hafting
2006-07-06 15:12 ` Ric Wheeler
2006-07-06 17:05 ` Krzysztof Halasa
2006-07-06 17:27 ` Ric Wheeler
2006-07-06 20:52 ` Valdis.Kletnieks
2006-07-07 17:41 ` Krzysztof Halasa
2006-07-07 17:34 ` Krzysztof Halasa
2006-07-04 1:02 ` Theodore Tso [this message]
2006-07-04 19:16 ` Thomas Glanzmann
2006-07-04 19:30 ` Valdis.Kletnieks
2006-07-05 12:24 ` Bill Davidsen
2006-07-05 12:59 ` J. Bruce Fields
2006-07-05 13:17 ` Pádraig Brady
2006-07-05 19:33 ` Trond Myklebust
2006-07-05 21:22 ` Bill Davidsen
2006-07-05 21:42 ` Trond Myklebust
2006-07-08 21:04 ` Bill Davidsen
2006-07-10 20:08 ` Trond Myklebust
2006-07-10 22:37 ` Bill Davidsen
2006-07-11 2:36 ` Trond Myklebust
2006-07-21 3:10 ` Bill Davidsen
2006-07-21 12:06 ` Trond Myklebust
2006-07-21 14:36 ` Theodore Tso
2006-07-21 19:02 ` Trond Myklebust
2006-07-22 12:25 ` Theodore Tso
2006-07-05 21:12 ` Bill Davidsen
2006-07-05 21:27 ` linux-os (Dick Johnson)
2006-07-05 21:41 ` J. Bruce Fields
2006-07-06 2:32 ` Bill Davidsen
2006-07-06 2:42 ` Nigel Cunningham
2006-07-06 12:43 ` Trond Myklebust
2006-07-07 2:15 ` Bill Davidsen
2006-07-07 2:30 ` Trond Myklebust
2006-07-07 2:42 ` Ric Wheeler
2006-07-07 2:46 ` Trond Myklebust
2006-07-07 3:16 ` Bill Davidsen
2006-07-07 8:09 ` Bernd Petrovitsch
2006-07-07 14:56 ` Trond Myklebust
2006-07-07 19:52 ` Theodore Tso
2006-07-05 14:04 ` Avi Kivity
2006-07-04 14:36 ` Andi Kleen
2006-07-04 14:43 ` Thomas Glanzmann
[not found] <6tVcC-1e1-79@gated-at.bofh.it>
[not found] ` <6tVcC-1e1-81@gated-at.bofh.it>
[not found] ` <6tVcC-1e1-83@gated-at.bofh.it>
[not found] ` <6tWib-2Ly-7@gated-at.bofh.it>
[not found] ` <6uDdv-7bs-3@gated-at.bofh.it>
[not found] ` <6uDGF-7Nj-47@gated-at.bofh.it>
[not found] ` <6uDQb-8e8-9@gated-at.bofh.it>
[not found] ` <6uDQb-8e8-13@gated-at.bofh.it>
[not found] ` <6uE9y-d1-1@gated-at.bofh.it>
[not found] ` <6uPom-87W-23@gated-at.bofh.it>
2006-07-04 12:28 ` Bodo Eggert
2006-07-04 15:32 ` Valdis.Kletnieks
[not found] ` <6uEMp-1gr-41@gated-at.bofh.it>
[not found] ` <6uUo2-6SN-5@gated-at.bofh.it>
[not found] ` <6uW6v-15i-19@gated-at.bofh.it>
[not found] ` <6vfLY-4K5-33@gated-at.bofh.it>
2006-07-05 22:40 ` Bodo Eggert
[not found] ` <6uXYv-3RG-1@gated-at.bofh.it>
[not found] ` <6veG8-350-7@gated-at.bofh.it>
[not found] ` <6vfiU-465-13@gated-at.bofh.it>
[not found] ` <6vmNk-77r-23@gated-at.bofh.it>
[not found] ` <6vnq7-7Tw-55@gated-at.bofh.it>
[not found] ` <6vrN0-5Se-9@gated-at.bofh.it>
[not found] ` <6vBsY-38p-9@gated-at.bofh.it>
2006-07-07 9:38 ` Bodo Eggert
2006-07-07 14:37 ` Trond Myklebust
2006-07-09 9:50 ` Bodo Eggert
-- strict thread matches above, loose matches on Subject: below --
2006-07-08 2:22 Chuck Ebbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060704010240.GD6317@thunk.org \
--to=tytso@mit.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=sithglan@stud.uni-erlangen.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox