Messages in this thread | | | Date | Sat, 08 Jul 2006 14:02:26 -0400 | From | Bill Davidsen <> | Subject | Re: ext4 features (checksums) |
| |
Avi Kivity wrote: > Bill Davidsen wrote: >> >> >> > Not syncing unused area is possible, if there was a way for raid resync >> > to ask the fs what blocks are not in use. I.e. get the >> > free block list in disk block order. Then raid resync could skip >> those. >> > >> Current RAID code supports having a bitmap of dirty stripes, and can >> just sync those during recovery. I'm sure Neil could explain it better, >> but this is available without worrying about fs type. Now. Today. >> > > This is only when the you reconstruct a disk that was once part of the > RAID. If you are adding a brand new disk, all stripes are dirty.
I will leave Neil to explain this to you, it appears to be a totally different case for reconfiguration, but I don't pretend to understand the code well enough to clarify it. > > This happens in two scenarios: an unclean RAID shutdown, and when you > have a remote mirror which can be disconnected by network problems. > > If the RAID is integrated in the filesystem (or into an object storage > system), you can handle the new disk case too. > I'm not sure that building the RAID into the filesystem is ever a good idea, it certainly seems likely to either prevent certain RAID devices from being used, or make them perform suboptimally. There are times when being able to move a filesystem to a new device is REALLY useful, and byte copy is more practical than file by file copy.
-- Bill Davidsen <davidsen@tmr.com> Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a normal user and is setuid root, with the "vi" line edit mode selected, and the character set is "big5," an off-by-one errors occurs during wildcard (glob) expansion. - 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/
| |