On Tue, 2005-12-20 at 14:06 +0100, Nicolas Mailhot wrote: > I don't know how anaconda handles it but the default raid IO limits are > very conservative (optimized for background work on a live system) > > On a system being created it's probably a better idea to tell the raid > system to pump as much blocks as possible, since this is a blocking op in > this context and we don't care about anything else. I think you miss the point. On a file system which is being created, the bandwidth limits _ought_ to be fairly much irrelevant. The file system is _empty_, and the total amount of I/O to create an empty RAID-1 ought to be almost exactly the same amount of I/O which it takes just to run 'mkfs' twice. The blocks which aren't yet used by the filesystem don't matter; you shouldn't need to sync their contents. RAID is just a hack which hides the redundancy from the file system; the kind of thing we always used to have to do for DOS compatibility so that we could provide an INT 13h handler and have it 'just work'. It's much the same reasoning which led to the built-in 'translation layers' on cheap CF cards and USB sticks which so often eat your data and which have a tendency to use up their limited lifetime in copying obsolete sectors belonging to deleted files around on the underlying medium. We don't _need_ that kind of layering in Linux. Have a library of functions which can be used for such redundancy, by all means -- but don't just make RAID pretend to be a 'standard' block device and prevent all possibility of sharing knowledge between the file system and the layer providing the redundancy. That's just insane. -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
