> yeah for a 'fast' solution moving from one file system to another > that > works with theses checks can help you, while we check if this is > usefull or not > > IMHO, if we implement this, we should implement outside any today > raid > levels, this should be done between device and filesystem, in others > words: > > we should implement this to work like: > DISKS - (OUR NEW SILENT ERROR SECURITY SYSTEM LEVEL, 1 PER DEVICE) - > TODAY RAID LEVELS - FILESYSTEMS > > or > > DISKS - RAIDS LEVELS - (OUR NEW SILENT ERROR SECURITY SYSTEM LEVEL, 1 > PER DEVICE) - FILESYSTEM > > or > > DISK - (OUR NEW SILENT ERROR SECURITY SYSTEM LEVEL, 1 PER DEVICE) - > FILESYSTEM > > > using this, we "could give more security" to usb pendrives for > example, and any block device (network block device, DRBD, or > anyother > block device in linux) Well ... it looks more modular, easier and could have more usecases. You're probably right at this point. Dracut maintainers would kill us both, but that's a different story. I'm only missing that possibility of immediate resyncing of the data when a corruption is detected. That's probably the only thing, that would be nice to have directly in the RAID layer (and could/should be also optional). J. -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
