Hi! > >> If you have a specific bug in MD code, please propose a patch. > > > > Interesting. So, what's technically wrong with the patch below? > > > > You mean apart from ".... that high highly undesirable ...." ?? > ^^^^^^^^^^^ > Ok, I still believe kernel documentation should be ... well... in kernel, not in LWN article, so I fixed the patch according to your comments. Signed-off-by: Pavel Machek <pavel@xxxxxx> diff --git a/Documentation/filesystems/dangers.txt b/Documentation/filesystems/dangers.txt new file mode 100644 index 0000000..14d0324 --- /dev/null +++ b/Documentation/filesystems/dangers.txt @@ -0,0 +1,21 @@ +There are storage devices that have highly undesirable properties when +they are disconnected or suffer power failures while writes are in +progress; such devices include flash devices and degraded DM/MD RAID +4/5/6 (*) arrays. These devices have the property of potentially +corrupting blocks being written at the time of the power failure, and +worse yet, amplifying the region where blocks are corrupted such that +additional sectors are also damaged during the power failure. + +Users who use such storage devices are well advised take +countermeasures, such as the use of Uninterruptible Power Supplies, +and making sure the flash device is not hot-unplugged while the device +is being used. Regular backups when using any devices, and these +devices in particular is also a Very Good Idea. + +Otherwise, file systems placed on these devices can suffer silent data +and file system corruption. An forced use of fsck may detect metadata +corruption resulting in file system corruption, but will not suffice +to detect data corruption. + +(*) If device failure causes the array to become degraded during or +immediately after the power failure, the same problem can result. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
