From: Pavel Machek <pavel@ucw.cz> To: Theodore Tso <tytso@mit.edu>, Rob Landley <rob@landley.net>, kernel list <linux-kernel@vger.kernel.org>, Andrew Morton <akpm@osdl.org>, mtk.manpages@gmail.com, rdunlap@xenotime.net, linux-doc@vger.kernel.org, linux-ext4@vger.kernel.org Subject: Re: ext2/3: document conditions when reliable operation is possible Date: Mon, 23 Mar 2009 19:23:41 +0100 [thread overview] Message-ID: <20090323182341.GA2695@elf.ucw.cz> (raw) In-Reply-To: <20090316190308.GE6357@mit.edu> Hi! > > > > Not all block devices are suitable for all filesystems. In fact, some > > > > block devices are so broken that reliable operation is pretty much > > > > impossible. Document stuff ext2/ext3 needs for reliable operation. > > Some of what is here are bugs, and some are legitimate long-term > interfaces (for example, the question of losing I/O errors when two > processes are writing to the same file, or to a directory entry, and > errors aren't or in some cases, can't, be reflected back to > userspace). Well, I guess there's thin line between error and "legitimate long-term interfaces". I still believe that fsync() is broken by design. > I'm a little concerned that some of this reads a bit too much like a > rant (and I know Pavel was very frustrated when he tried to use a > flash card with a sucky flash card socket) and it will get used the It started as a rant, obviously I'd like to get away from that and get it into suitable format for inclusion. (Not being native speaker does not help here). But I do believe that we should get this documented; many common storage subsystems are broken, and can cause data loss. We should at least tell to the users. > wrong way by apoligists, because it mixes areas where "we suck, we > should do better", which a re bug reports, and "Posix or the > underlying block device layer makes it hard", and simply states them > as fundamental design requirements, when that's probably not true. Well, I guess that can be refined later. Heck, I'm not able to tell which are simple bugs likely to be fixed soon, and which are fundamental issues that are unlikely to be fixed sooner than 2030. I guess it is fair to document them ASAP, and then fix those that can be fixed... > There's a lot of work that we could do to make I/O errors get better > reflected to userspace by fsync(). So state things as bald > requirements I think goes a little too far IMHO. We can surely do > better. If the fsync() can be fixed... that would be great. But I'm not sure how easy that will be. > > +Write errors not allowed (NO-WRITE-ERRORS) > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > + > > +Writes to media never fail. Even if disk returns error condition > > +during write, filesystems can't handle that correctly, because success > > +on fsync was already returned when data hit the journal. > > The last half of this sentence "because success on fsync was already > returned when data hit the journal", obviously doesn't apply to all > filesystems, since some filesystems, like ext2, don't journal data. > Even for ext3, it only applies in the case of data=journal mode. Ok, I removed the explanation. > There are other issues here, such as fsync() only reports an I/O > problem to one caller, and in some cases I/O errors aren't propagated > up the storage stack. The latter is clearly just a bug that should be > fixed; the former is more of an interface limitation. But you don't > talk about in this section, and I think it would be good to have a > more extended discussion about I/O errors when writing data blocks, > and I/O errors writing metadata blocks, etc. Could you write a paragraph or two? > > + > > +Sector writes are atomic (ATOMIC-SECTORS) > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > + > > +Either whole sector is correctly written or nothing is written during > > +powerfail. > > This requirement is not quite the same as what you discuss below. Ok, you are right. Fixed. > So there are actually two desirable properties for a storage system to > have; one is "don't damage the old data on a failed write"; and the > other is "don't cause collateral damage to adjacent sectors on a > failed write". Thanks, its indeed clearer that way. I split those in two. > > + Because RAM tends to fail faster than rest of system during > > + powerfail, special hw killing DMA transfers may be necessary; > > + otherwise, disks may write garbage during powerfail. > > + Not sure how common that problem is on generic PC machines. > > This problem is still relatively common, from what I can tell. And > ext3 handles this surprisingly well at least in the catastrophic case > of garbage getting written into the inode table, since the journal > replay often will "repair" the garbage that was written into the ... Ok, added to ext3 specific section. New version is attached. Feel free to help here; my goal is to get this documented, I'm not particulary attached to wording etc... Signed-off-by: Pavel Machek <pavel@ucw.cz> Pavel diff --git a/Documentation/filesystems/expectations.txt b/Documentation/filesystems/expectations.txt new file mode 100644 index 0000000..0de456d --- /dev/null +++ b/Documentation/filesystems/expectations.txt @@ -0,0 +1,49 @@ +Linux block-backed filesystems can only work correctly when several +conditions are met in the block layer and below (disks, flash +cards). Some of them are obvious ("data on media should not change +randomly"), some are less so. + +Write errors not allowed (NO-WRITE-ERRORS) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Writes to media never fail. Even if disk returns error condition +during write, filesystems can't handle that correctly. + + Fortunately writes failing are very uncommon on traditional + spinning disks, as they have spare sectors they use when write + fails. + +Don't cause collateral damage to adjacent sectors on a failed write (NO-COLLATERALS) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Unfortunately, cheap USB/SD flash cards I've seen do have this bug, +and are thus unsuitable for all filesystems I know. + + An inherent problem with using flash as a normal block device + is that the flash erase size is bigger than most filesystem + sector sizes. So when you request a write, it may erase and + rewrite some 64k, 128k, or even a couple megabytes on the + really _big_ ones. + + If you lose power in the middle of that, filesystem won't + notice that data in the "sectors" _around_ the one your were + trying to write to got trashed. + + +Don't damage the old data on a failed write (ATOMIC-WRITES) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Either whole sector is correctly written or nothing is written during +powerfail. + + Because RAM tends to fail faster than rest of system during + powerfail, special hw killing DMA transfers may be necessary; + otherwise, disks may write garbage during powerfail. + This may be quite common on generic PC machines. + + Note that atomic write is very hard to guarantee for RAID-4/5/6, + because it needs to write both changed data, and parity, to + different disks. UPS for RAID array should help. + + + diff --git a/Documentation/filesystems/ext2.txt b/Documentation/filesystems/ext2.txt index 2344855..ee88467 100644 --- a/Documentation/filesystems/ext2.txt +++ b/Documentation/filesystems/ext2.txt @@ -338,27 +339,30 @@ enough 4-character names to make up unique directory entries, so they have to be 8 character filenames, even then we are fairly close to running out of unique filenames. +Requirements +============ + +Ext2 expects disk/storage subsystem to behave sanely. On sanely +behaving disk subsystem, data that have been successfully synced will +stay on the disk. Sane means: + +* write errors not allowed (NO-WRITE-ERRORS) + +* don't damage the old data on a failed write (ATOMIC-WRITES) + +and obviously: + +* don't cause collateral damage to adjacent sectors on a failed write + (NO-COLLATERALS) + +(see expectations.txt; note that most/all linux block-based +filesystems have similar expectations) + +* write caching is disabled. ext2 does not know how to issue barriers + as of 2.6.28. hdparm -W0 disables it on SATA disks. + Journaling ----------- - -A journaling extension to the ext2 code has been developed by Stephen -Tweedie. It avoids the risks of metadata corruption and the need to -wait for e2fsck to complete after a crash, without requiring a change -to the on-disk ext2 layout. In a nutshell, the journal is a regular -file which stores whole metadata (and optionally data) blocks that have -been modified, prior to writing them into the filesystem. This means -it is possible to add a journal to an existing ext2 filesystem without -the need for data conversion. - -When changes to the filesystem (e.g. a file is renamed) they are stored in -a transaction in the journal and can either be complete or incomplete at -the time of a crash. If a transaction is complete at the time of a crash -(or in the normal case where the system does not crash), then any blocks -in that transaction are guaranteed to represent a valid filesystem state, -and are copied into the filesystem. If a transaction is incomplete at -the time of the crash, then there is no guarantee of consistency for -the blocks in that transaction so they are discarded (which means any -filesystem changes they represent are also lost). +========== Check Documentation/filesystems/ext3.txt if you want to read more about ext3 and journaling. diff --git a/Documentation/filesystems/ext3.txt b/Documentation/filesystems/ext3.txt index e5f3833..6de8af4 100644 --- a/Documentation/filesystems/ext3.txt +++ b/Documentation/filesystems/ext3.txt @@ -188,6 +200,45 @@ mke2fs: create a ext3 partition with the -j flag. debugfs: ext2 and ext3 file system debugger. ext2online: online (mounted) ext2 and ext3 filesystem resizer +Requirements +============ + +Ext3 expects disk/storage subsystem to behave sanely. On sanely +behaving disk subsystem, data that have been successfully synced will +stay on the disk. Sane means: + +* write errors not allowed (NO-WRITE-ERRORS) + +* don't damage the old data on a failed write (ATOMIC-WRITES) + + (Thrash may get written into sectors during powerfail. And + ext3 handles this surprisingly well at least in the + catastrophic case of garbage getting written into the inode + table, since the journal replay often will "repair" the + garbage that was written into the filesystem metadata blocks. + It won't do a bit of good for the data blocks, of course + (unless you are using data=journal mode). But this means that + in fact, ext3 is more resistant to suriving failures to the + first problem (powerfail while writing can damage old data on + a failed write) but fortunately, hard drives generally don't + cause collateral damage on a failed write. + +and obviously: + +* don't cause collateral damage to adjacent sectors on a failed write + (NO-COLLATERALS) + + +(see expectations.txt; note that most/all linux block-based +filesystems have similar expectations) + +* either write caching is disabled, or hw can do barriers and they are enabled. + + (Note that barriers are disabled by default, use "barrier=1" + mount option after making sure hw can support them). + + hdparm -I reports disk features. If you have "Native + Command Queueing" is the feature you are looking for. References ========== -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@ucw.cz> To: Theodore Tso <tytso@mit.edu>, Rob Landley <rob@landley.net>, kernel list <linux-kernel@vger.kernel.org>, Andrew Morton <akpm@osdl.org>, mtk.manpages@gmail.com, rdunlap@xenotime.net, l Subject: Re: ext2/3: document conditions when reliable operation is possible Date: Mon, 23 Mar 2009 19:23:41 +0100 [thread overview] Message-ID: <20090323182341.GA2695@elf.ucw.cz> (raw) In-Reply-To: <20090316190308.GE6357@mit.edu> Hi! > > > > Not all block devices are suitable for all filesystems. In fact, some > > > > block devices are so broken that reliable operation is pretty much > > > > impossible. Document stuff ext2/ext3 needs for reliable operation. > > Some of what is here are bugs, and some are legitimate long-term > interfaces (for example, the question of losing I/O errors when two > processes are writing to the same file, or to a directory entry, and > errors aren't or in some cases, can't, be reflected back to > userspace). Well, I guess there's thin line between error and "legitimate long-term interfaces". I still believe that fsync() is broken by design. > I'm a little concerned that some of this reads a bit too much like a > rant (and I know Pavel was very frustrated when he tried to use a > flash card with a sucky flash card socket) and it will get used the It started as a rant, obviously I'd like to get away from that and get it into suitable format for inclusion. (Not being native speaker does not help here). But I do believe that we should get this documented; many common storage subsystems are broken, and can cause data loss. We should at least tell to the users. > wrong way by apoligists, because it mixes areas where "we suck, we > should do better", which a re bug reports, and "Posix or the > underlying block device layer makes it hard", and simply states them > as fundamental design requirements, when that's probably not true. Well, I guess that can be refined later. Heck, I'm not able to tell which are simple bugs likely to be fixed soon, and which are fundamental issues that are unlikely to be fixed sooner than 2030. I guess it is fair to document them ASAP, and then fix those that can be fixed... > There's a lot of work that we could do to make I/O errors get better > reflected to userspace by fsync(). So state things as bald > requirements I think goes a little too far IMHO. We can surely do > better. If the fsync() can be fixed... that would be great. But I'm not sure how easy that will be. > > +Write errors not allowed (NO-WRITE-ERRORS) > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > + > > +Writes to media never fail. Even if disk returns error condition > > +during write, filesystems can't handle that correctly, because success > > +on fsync was already returned when data hit the journal. > > The last half of this sentence "because success on fsync was already > returned when data hit the journal", obviously doesn't apply to all > filesystems, since some filesystems, like ext2, don't journal data. > Even for ext3, it only applies in the case of data=journal mode. Ok, I removed the explanation. > There are other issues here, such as fsync() only reports an I/O > problem to one caller, and in some cases I/O errors aren't propagated > up the storage stack. The latter is clearly just a bug that should be > fixed; the former is more of an interface limitation. But you don't > talk about in this section, and I think it would be good to have a > more extended discussion about I/O errors when writing data blocks, > and I/O errors writing metadata blocks, etc. Could you write a paragraph or two? > > + > > +Sector writes are atomic (ATOMIC-SECTORS) > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > + > > +Either whole sector is correctly written or nothing is written during > > +powerfail. > > This requirement is not quite the same as what you discuss below. Ok, you are right. Fixed. > So there are actually two desirable properties for a storage system to > have; one is "don't damage the old data on a failed write"; and the > other is "don't cause collateral damage to adjacent sectors on a > failed write". Thanks, its indeed clearer that way. I split those in two. > > + Because RAM tends to fail faster than rest of system during > > + powerfail, special hw killing DMA transfers may be necessary; > > + otherwise, disks may write garbage during powerfail. > > + Not sure how common that problem is on generic PC machines. > > This problem is still relatively common, from what I can tell. And > ext3 handles this surprisingly well at least in the catastrophic case > of garbage getting written into the inode table, since the journal > replay often will "repair" the garbage that was written into the ... Ok, added to ext3 specific section. New version is attached. Feel free to help here; my goal is to get this documented, I'm not particulary attached to wording etc... Signed-off-by: Pavel Machek <pavel@ucw.cz> Pavel diff --git a/Documentation/filesystems/expectations.txt b/Documentation/filesystems/expectations.txt new file mode 100644 index 0000000..0de456d --- /dev/null +++ b/Documentation/filesystems/expectations.txt @@ -0,0 +1,49 @@ +Linux block-backed filesystems can only work correctly when several +conditions are met in the block layer and below (disks, flash +cards). Some of them are obvious ("data on media should not change +randomly"), some are less so. + +Write errors not allowed (NO-WRITE-ERRORS) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Writes to media never fail. Even if disk returns error condition +during write, filesystems can't handle that correctly. + + Fortunately writes failing are very uncommon on traditional + spinning disks, as they have spare sectors they use when write + fails. + +Don't cause collateral damage to adjacent sectors on a failed write (NO-COLLATERALS) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Unfortunately, cheap USB/SD flash cards I've seen do have this bug, +and are thus unsuitable for all filesystems I know. + + An inherent problem with using flash as a normal block device + is that the flash erase size is bigger than most filesystem + sector sizes. So when you request a write, it may erase and + rewrite some 64k, 128k, or even a couple megabytes on the + really _big_ ones. + + If you lose power in the middle of that, filesystem won't + notice that data in the "sectors" _around_ the one your were + trying to write to got trashed. + + +Don't damage the old data on a failed write (ATOMIC-WRITES) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Either whole sector is correctly written or nothing is written during +powerfail. + + Because RAM tends to fail faster than rest of system during + powerfail, special hw killing DMA transfers may be necessary; + otherwise, disks may write garbage during powerfail. + This may be quite common on generic PC machines. + + Note that atomic write is very hard to guarantee for RAID-4/5/6, + because it needs to write both changed data, and parity, to + different disks. UPS for RAID array should help. + + + diff --git a/Documentation/filesystems/ext2.txt b/Documentation/filesystems/ext2.txt index 2344855..ee88467 100644 --- a/Documentation/filesystems/ext2.txt +++ b/Documentation/filesystems/ext2.txt @@ -338,27 +339,30 @@ enough 4-character names to make up unique directory entries, so they have to be 8 character filenames, even then we are fairly close to running out of unique filenames. +Requirements +============ + +Ext2 expects disk/storage subsystem to behave sanely. On sanely +behaving disk subsystem, data that have been successfully synced will +stay on the disk. Sane means: + +* write errors not allowed (NO-WRITE-ERRORS) + +* don't damage the old data on a failed write (ATOMIC-WRITES) + +and obviously: + +* don't cause collateral damage to adjacent sectors on a failed write + (NO-COLLATERALS) + +(see expectations.txt; note that most/all linux block-based +filesystems have similar expectations) + +* write caching is disabled. ext2 does not know how to issue barriers + as of 2.6.28. hdparm -W0 disables it on SATA disks. + Journaling ----------- - -A journaling extension to the ext2 code has been developed by Stephen -Tweedie. It avoids the risks of metadata corruption and the need to -wait for e2fsck to complete after a crash, without requiring a change -to the on-disk ext2 layout. In a nutshell, the journal is a regular -file which stores whole metadata (and optionally data) blocks that have -been modified, prior to writing them into the filesystem. This means -it is possible to add a journal to an existing ext2 filesystem without -the need for data conversion. - -When changes to the filesystem (e.g. a file is renamed) they are stored in -a transaction in the journal and can either be complete or incomplete at -the time of a crash. If a transaction is complete at the time of a crash -(or in the normal case where the system does not crash), then any blocks -in that transaction are guaranteed to represent a valid filesystem state, -and are copied into the filesystem. If a transaction is incomplete at -the time of the crash, then there is no guarantee of consistency for -the blocks in that transaction so they are discarded (which means any -filesystem changes they represent are also lost). +========== Check Documentation/filesystems/ext3.txt if you want to read more about ext3 and journaling. diff --git a/Documentation/filesystems/ext3.txt b/Documentation/filesystems/ext3.txt index e5f3833..6de8af4 100644 --- a/Documentation/filesystems/ext3.txt +++ b/Documentation/filesystems/ext3.txt @@ -188,6 +200,45 @@ mke2fs: create a ext3 partition with the -j flag. debugfs: ext2 and ext3 file system debugger. ext2online: online (mounted) ext2 and ext3 filesystem resizer +Requirements +============ + +Ext3 expects disk/storage subsystem to behave sanely. On sanely +behaving disk subsystem, data that have been successfully synced will +stay on the disk. Sane means: + +* write errors not allowed (NO-WRITE-ERRORS) + +* don't damage the old data on a failed write (ATOMIC-WRITES) + + (Thrash may get written into sectors during powerfail. And + ext3 handles this surprisingly well at least in the + catastrophic case of garbage getting written into the inode + table, since the journal replay often will "repair" the + garbage that was written into the filesystem metadata blocks. + It won't do a bit of good for the data blocks, of course + (unless you are using data=journal mode). But this means that + in fact, ext3 is more resistant to suriving failures to the + first problem (powerfail while writing can damage old data on + a failed write) but fortunately, hard drives generally don't + cause collateral damage on a failed write. + +and obviously: + +* don't cause collateral damage to adjacent sectors on a failed write + (NO-COLLATERALS) + + +(see expectations.txt; note that most/all linux block-based +filesystems have similar expectations) + +* either write caching is disabled, or hw can do barriers and they are enabled. + + (Note that barriers are disabled by default, use "barrier=1" + mount option after making sure hw can support them). + + hdparm -I reports disk features. If you have "Native + Command Queueing" is the feature you are looking for. References ========== -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2009-03-23 18:21 UTC|newest] Thread overview: 309+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-03-12 9:21 ext2/3: document conditions when reliable operation is possible Pavel Machek 2009-03-12 11:40 ` Jochen Voß 2009-03-21 11:24 ` Pavel Machek 2009-03-21 11:24 ` Pavel Machek 2009-03-12 19:13 ` Rob Landley 2009-03-16 12:28 ` Pavel Machek 2009-03-16 19:26 ` Rob Landley 2009-03-23 10:45 ` Pavel Machek 2009-03-30 15:06 ` Goswin von Brederlow 2009-08-24 9:26 ` Pavel Machek 2009-08-24 9:31 ` [patch] " Pavel Machek 2009-08-24 11:19 ` Florian Weimer 2009-08-24 13:01 ` Theodore Tso 2009-08-24 14:55 ` Artem Bityutskiy 2009-08-24 22:30 ` Rob Landley 2009-08-24 19:52 ` Pavel Machek 2009-08-24 19:52 ` Pavel Machek 2009-08-24 20:24 ` Ric Wheeler 2009-08-24 20:52 ` Pavel Machek 2009-08-24 21:08 ` Ric Wheeler 2009-08-24 21:25 ` Pavel Machek 2009-08-24 22:05 ` Ric Wheeler 2009-08-24 22:22 ` Zan Lynx 2009-08-24 22:44 ` Pavel Machek 2009-08-25 0:34 ` Ric Wheeler 2009-08-24 23:42 ` david 2009-08-24 22:41 ` Pavel Machek 2009-08-24 22:39 ` Theodore Tso 2009-08-24 23:00 ` Pavel Machek 2009-08-25 0:02 ` david 2009-08-25 9:32 ` Pavel Machek 2009-08-25 0:06 ` Ric Wheeler 2009-08-25 9:34 ` Pavel Machek 2009-08-25 15:34 ` david 2009-08-26 3:32 ` Rik van Riel 2009-08-26 11:17 ` Pavel Machek 2009-08-26 11:29 ` david 2009-08-26 13:10 ` Pavel Machek 2009-08-26 13:43 ` david 2009-08-26 18:02 ` Theodore Tso 2009-08-27 6:28 ` Eric Sandeen 2009-08-27 6:28 ` Eric Sandeen 2009-11-09 8:53 ` periodic fsck was " Pavel Machek 2009-11-09 8:53 ` Pavel Machek 2009-11-09 14:05 ` Theodore Tso 2009-11-09 15:58 ` Andreas Dilger 2009-08-30 7:03 ` Pavel Machek 2009-08-26 12:28 ` Theodore Tso 2009-08-27 6:06 ` Rob Landley 2009-08-27 6:54 ` david 2009-08-27 7:34 ` Rob Landley 2009-08-28 14:37 ` david 2009-08-30 7:19 ` Pavel Machek 2009-08-30 12:48 ` david 2009-08-27 5:27 ` Rob Landley 2009-08-25 0:08 ` Theodore Tso 2009-08-25 9:42 ` Pavel Machek 2009-08-25 9:42 ` Pavel Machek 2009-08-25 13:37 ` Ric Wheeler 2009-08-25 13:42 ` Alan Cox 2009-08-27 3:16 ` Rob Landley 2009-08-25 21:15 ` Pavel Machek 2009-08-25 22:42 ` Ric Wheeler 2009-08-25 22:51 ` Pavel Machek 2009-08-25 23:03 ` david 2009-08-25 23:29 ` Pavel Machek 2009-08-25 23:03 ` Ric Wheeler 2009-08-25 23:26 ` Pavel Machek 2009-08-25 23:40 ` Ric Wheeler 2009-08-25 23:48 ` david 2009-08-25 23:53 ` Pavel Machek 2009-08-26 0:11 ` Ric Wheeler 2009-08-26 0:16 ` Pavel Machek 2009-08-26 0:31 ` Ric Wheeler 2009-08-26 1:00 ` Theodore Tso 2009-08-26 1:15 ` Ric Wheeler 2009-08-26 2:58 ` Theodore Tso 2009-08-26 10:39 ` Ric Wheeler 2009-08-26 10:39 ` Ric Wheeler 2009-08-26 11:12 ` Pavel Machek 2009-08-26 11:28 ` david 2009-08-29 9:49 ` [testcase] test your fs/storage stack (was Re: [patch] ext2/3: document conditions when reliable operation is possible) Pavel Machek 2009-08-29 11:28 ` Ric Wheeler 2009-09-02 20:12 ` Pavel Machek 2009-09-02 20:42 ` Ric Wheeler 2009-09-02 23:00 ` Rob Landley 2009-09-02 23:09 ` david 2009-09-03 8:55 ` Pavel Machek 2009-09-03 0:36 ` jim owens 2009-09-03 2:41 ` Rob Landley 2009-09-03 14:14 ` jim owens 2009-09-04 7:44 ` Rob Landley 2009-09-04 11:49 ` Ric Wheeler 2009-09-05 10:28 ` Pavel Machek 2009-09-05 12:20 ` Ric Wheeler 2009-09-05 13:54 ` Jonathan Corbet 2009-09-05 21:27 ` Pavel Machek 2009-09-05 21:56 ` Theodore Tso 2009-09-02 22:45 ` Rob Landley 2009-09-02 22:49 ` [PATCH] Update Documentation/md.txt to mention journaling won't help dirty+degraded case Rob Landley 2009-09-03 9:08 ` Pavel Machek 2009-09-03 12:05 ` Ric Wheeler 2009-09-03 12:31 ` Pavel Machek 2009-08-29 16:35 ` [testcase] test your fs/storage stack (was Re: [patch] ext2/3: document conditions when reliable operation is possible) david 2009-08-29 16:35 ` david 2009-08-30 7:07 ` Pavel Machek 2009-08-26 12:01 ` [patch] ext2/3: document conditions when reliable operation is possible Ric Wheeler 2009-08-26 12:23 ` Theodore Tso 2009-08-30 7:01 ` Pavel Machek 2009-08-30 7:01 ` Pavel Machek 2009-08-27 5:19 ` Rob Landley 2009-08-27 12:24 ` Theodore Tso 2009-08-27 13:10 ` Ric Wheeler 2009-08-27 13:10 ` Ric Wheeler 2009-08-27 16:54 ` MD/DM and barriers (was Re: [patch] ext2/3: document conditions when reliable operation is possible) Jeff Garzik 2009-08-27 18:09 ` Alasdair G Kergon 2009-09-01 14:01 ` Pavel Machek 2009-09-02 16:17 ` Michael Tokarev 2009-08-29 10:02 ` [patch] ext2/3: document conditions when reliable operation is possible Pavel Machek 2009-08-29 10:02 ` Pavel Machek 2009-08-26 1:15 ` Ric Wheeler 2009-08-26 1:16 ` Pavel Machek 2009-08-26 1:16 ` Pavel Machek 2009-08-26 2:55 ` Theodore Tso 2009-08-26 13:37 ` Ric Wheeler 2009-08-26 13:37 ` Ric Wheeler 2009-08-26 2:53 ` Henrique de Moraes Holschuh 2009-08-26 2:53 ` Henrique de Moraes Holschuh 2009-09-03 9:47 ` Pavel Machek 2009-09-03 9:47 ` Pavel Machek 2009-08-26 3:50 ` Rik van Riel 2009-08-27 3:53 ` Rob Landley 2009-08-27 11:43 ` Ric Wheeler 2009-08-27 20:51 ` Rob Landley 2009-08-27 22:00 ` Ric Wheeler 2009-08-28 14:49 ` david 2009-08-29 10:05 ` Pavel Machek 2009-08-29 20:22 ` Rob Landley 2009-08-29 21:34 ` Pavel Machek 2009-09-03 16:56 ` what fsck can (and can't) do was " david 2009-09-03 19:27 ` Theodore Tso 2009-08-27 22:13 ` raid is dangerous but that's secret (was Re: [patch] ext2/3: document conditions when reliable operation is possible) Pavel Machek 2009-08-28 1:32 ` Ric Wheeler 2009-08-28 6:44 ` Pavel Machek 2009-08-28 7:31 ` NeilBrown 2009-08-28 7:31 ` NeilBrown 2009-11-09 10:50 ` Pavel Machek 2009-08-28 11:16 ` Ric Wheeler 2009-09-01 13:58 ` Pavel Machek 2009-08-28 7:11 ` raid is dangerous but that's secret Florian Weimer 2009-08-28 7:23 ` NeilBrown 2009-08-28 12:08 ` raid is dangerous but that's secret (was Re: [patch] ext2/3: document conditions when reliable operation is possible) Theodore Tso 2009-08-30 7:51 ` Pavel Machek 2009-08-30 9:01 ` Christian Kujau 2009-09-02 20:55 ` Pavel Machek 2009-08-30 12:55 ` david 2009-08-30 14:12 ` Ric Wheeler 2009-08-30 14:44 ` Michael Tokarev 2009-08-30 16:10 ` Ric Wheeler 2009-08-30 16:35 ` Christoph Hellwig 2009-08-31 13:15 ` Ric Wheeler 2009-08-31 13:16 ` Christoph Hellwig 2009-08-31 13:19 ` Mark Lord 2009-08-31 13:21 ` Christoph Hellwig 2009-08-31 15:14 ` jim owens 2009-09-03 1:59 ` Ric Wheeler 2009-09-03 11:12 ` Krzysztof Halasa 2009-09-03 11:18 ` Ric Wheeler 2009-09-03 13:34 ` Krzysztof Halasa 2009-09-03 13:50 ` Ric Wheeler 2009-09-03 13:59 ` Krzysztof Halasa 2009-09-03 14:15 ` wishful thinking about atomic, multi-sector or full MD stripe width, writes in storage Ric Wheeler 2009-09-03 14:26 ` Florian Weimer 2009-09-03 15:09 ` Ric Wheeler 2009-09-03 23:50 ` Krzysztof Halasa 2009-09-04 0:39 ` Ric Wheeler 2009-09-04 21:21 ` Mark Lord 2009-09-04 21:29 ` Ric Wheeler 2009-09-05 12:57 ` Mark Lord 2009-09-05 13:40 ` Ric Wheeler 2009-09-05 21:43 ` NeilBrown 2009-09-07 11:45 ` Pavel Machek 2009-09-07 13:10 ` Theodore Tso 2010-04-04 13:47 ` fsck more often when powerfail is detected (was Re: wishful thinking about atomic, multi-sector or full MD stripe width, writes in storage) Pavel Machek 2010-04-04 13:47 ` Pavel Machek 2010-04-04 17:39 ` tytso 2010-04-04 17:59 ` Rob Landley 2010-04-04 18:45 ` Pavel Machek 2010-04-04 19:35 ` tytso 2010-04-04 19:29 ` tytso 2010-04-04 23:58 ` Rob Landley 2009-09-03 14:35 ` raid is dangerous but that's secret (was Re: [patch] ext2/3: document conditions when reliable operation is possible) david 2009-08-31 13:22 ` Ric Wheeler 2009-08-31 15:50 ` david 2009-08-31 16:21 ` Ric Wheeler 2009-08-31 18:31 ` Christoph Hellwig 2009-08-31 19:11 ` david 2009-08-30 15:05 ` Pavel Machek 2009-08-30 15:20 ` Theodore Tso 2009-08-31 17:49 ` Jesse Brandeburg 2009-08-31 18:01 ` Ric Wheeler 2009-08-31 21:01 ` MD5/6? (was Re: raid is dangerous but that's secret ...) Ron Johnson 2009-08-31 18:07 ` raid is dangerous but that's secret (was Re: [patch] ext2/3: document conditions when reliable operation is possible) martin f krafft 2009-08-31 22:26 ` Jesse Brandeburg 2009-08-31 22:26 ` Jesse Brandeburg 2009-08-31 23:19 ` Ron Johnson 2009-09-01 5:45 ` martin f krafft 2009-08-31 17:49 ` Jesse Brandeburg 2009-09-05 10:34 ` Pavel Machek 2009-09-05 10:34 ` Pavel Machek 2009-08-30 7:51 ` Pavel Machek 2009-08-25 23:46 ` [patch] ext2/3: document conditions when reliable operation is possible david 2009-08-25 23:08 ` Neil Brown 2009-08-25 23:44 ` Pavel Machek 2009-08-26 4:08 ` Rik van Riel 2009-08-26 11:15 ` Pavel Machek 2009-08-27 3:29 ` Rik van Riel 2009-08-25 16:11 ` Theodore Tso 2009-08-25 22:21 ` [patch] document flash/RAID dangers Pavel Machek 2009-08-25 22:21 ` Pavel Machek 2009-08-25 22:33 ` david 2009-08-25 22:40 ` Pavel Machek 2009-08-25 22:59 ` david 2009-08-25 23:37 ` Pavel Machek 2009-08-25 23:48 ` Ric Wheeler 2009-08-26 0:06 ` Pavel Machek 2009-08-26 0:12 ` Ric Wheeler 2009-08-26 0:20 ` Pavel Machek 2009-08-26 0:26 ` david 2009-08-26 0:28 ` Ric Wheeler 2009-08-26 0:38 ` Pavel Machek 2009-08-26 0:45 ` Ric Wheeler 2009-08-26 11:21 ` Pavel Machek 2009-08-26 11:58 ` Ric Wheeler 2009-08-26 12:40 ` Theodore Tso 2009-08-26 13:11 ` Ric Wheeler 2009-08-26 13:11 ` Ric Wheeler 2009-08-26 13:44 ` david 2009-08-26 13:40 ` Chris Adams 2009-08-26 13:47 ` Alan Cox 2009-08-26 14:11 ` Chris Adams 2009-08-27 21:50 ` Pavel Machek 2009-08-29 9:38 ` Pavel Machek 2009-08-26 4:24 ` Rik van Riel 2009-08-26 11:22 ` Pavel Machek 2009-08-26 14:45 ` Rik van Riel 2009-08-29 9:39 ` Pavel Machek 2009-08-29 11:47 ` Ron Johnson 2009-08-29 16:12 ` jim owens 2009-08-25 23:56 ` david 2009-08-26 0:12 ` Pavel Machek 2009-08-26 0:20 ` david 2009-08-26 0:39 ` Pavel Machek 2009-08-26 1:17 ` david 2009-08-26 0:26 ` Ric Wheeler 2009-08-26 0:44 ` Pavel Machek 2009-08-26 0:50 ` Ric Wheeler 2009-08-26 1:19 ` david 2009-08-26 11:25 ` Pavel Machek 2009-08-26 12:37 ` Theodore Tso 2009-08-30 6:49 ` Pavel Machek 2009-08-30 6:49 ` Pavel Machek 2009-08-26 4:20 ` Rik van Riel 2009-08-25 22:27 ` [patch] document that ext2 can't handle barriers Pavel Machek 2009-08-25 22:27 ` Pavel Machek 2009-08-27 3:34 ` [patch] ext2/3: document conditions when reliable operation is possible Rob Landley 2009-08-27 8:46 ` David Woodhouse 2009-08-28 14:46 ` david 2009-08-29 10:09 ` Pavel Machek 2009-08-29 16:27 ` david 2009-08-29 21:33 ` Pavel Machek 2009-08-24 23:00 ` Pavel Machek 2009-08-25 13:57 ` Chris Adams 2009-08-25 22:58 ` Neil Brown 2009-08-25 23:10 ` Ric Wheeler 2009-08-25 23:32 ` NeilBrown 2009-08-25 23:32 ` NeilBrown 2009-08-24 21:11 ` Greg Freemyer 2009-08-24 21:11 ` Greg Freemyer 2009-08-25 20:56 ` Rob Landley 2009-08-25 21:08 ` david 2009-08-25 18:52 ` Rob Landley 2009-08-25 14:43 ` Florian Weimer 2009-08-24 13:50 ` Theodore Tso 2009-08-24 18:48 ` Pavel Machek 2009-08-24 18:48 ` Pavel Machek 2009-08-24 18:39 ` Pavel Machek 2009-08-24 13:21 ` Greg Freemyer 2009-08-24 13:21 ` Greg Freemyer 2009-08-24 18:44 ` Pavel Machek 2009-08-25 23:28 ` Neil Brown 2009-08-25 23:28 ` Neil Brown 2009-08-26 1:34 ` david 2009-08-24 21:11 ` Rob Landley 2009-08-24 21:33 ` Pavel Machek 2009-08-25 18:45 ` Jan Kara 2009-03-16 12:30 ` Pavel Machek 2009-03-16 19:03 ` Theodore Tso 2009-03-23 18:23 ` Pavel Machek [this message] 2009-03-23 18:23 ` Pavel Machek 2009-03-16 19:40 ` Sitsofe Wheeler 2009-03-16 21:43 ` Rob Landley 2009-03-17 4:55 ` Kyle Moffett 2009-03-23 11:00 ` Pavel Machek 2009-08-29 1:33 ` Robert Hancock 2009-08-29 13:04 ` Alan Cox 2009-03-16 19:45 ` Greg Freemyer 2009-03-16 19:45 ` Greg Freemyer 2009-03-16 21:48 ` Pavel Machek [not found] <dddMw-7Xt-57@gated-at.bofh.it> [not found] ` <dddWc-83W-51@gated-at.bofh.it> [not found] ` <ddefx-5R-37@gated-at.bofh.it> [not found] ` <ddep7-bI-7@gated-at.bofh.it> [not found] ` <ddeyR-iy-11@gated-at.bofh.it> [not found] ` <ddeyR-iy-9@gated-at.bofh.it> [not found] ` <ddeIu-n9-9@gated-at.bofh.it> [not found] ` <ddeSb-th-29@gated-at.bofh.it> [not found] ` <ddoRI-11a-39@gated-at.bofh.it> [not found] <ciPTu-7f2-47@gated-at.bofh.it> [not found] ` <clrhX-3R1-13@gated-at.bofh.it> [not found] ` <dcEc1-33Z-17@gated-at.bofh.it> [not found] ` <dcFUz-4yN-9@gated-at.bofh.it> [not found] ` <dcHtf-5XC-17@gated-at.bofh.it> [not found] ` <dcNSc-2DU-11@gated-at.bofh.it> [not found] ` <dcOl9-3aC-19@gated-at.bofh.it> [not found] ` <dcOOd-3qM-33@gated-at.bofh.it> [not found] ` <dcOXN-3M5-15@gated-at.bofh.it>
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=20090323182341.GA2695@elf.ucw.cz \ --to=pavel@ucw.cz \ --cc=akpm@osdl.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mtk.manpages@gmail.com \ --cc=rdunlap@xenotime.net \ --cc=rob@landley.net \ --cc=tytso@mit.edu \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.