On Mon, Jan 13, 2014 at 09:06:45AM -0500, Theodore Ts'o wrote: > On Mon, Jan 13, 2014 at 11:27:08AM -0200, Carlos Maiolino wrote: > > I'm not really a big fan of removing more backup metadata blocks > > than we already have with the sparse_super feature, but, giving the > > SMR writing system, this might save the filesystem from a lot of > > fragmentation when updating the backup superblocks. > > Not only that, but the backup superblocks become extra things for the > SMR subsystem to have to copy around. > > > I'm just wondering if it might not be interesting in still have the > > backup superblock into the last block group, but I'm not really sure > > about the concerns it might have when resizing a filesystem. This > > might add more problems than the benefits :) > > Yes, I thought about putting the backup superblock either at the very > last block group, or at the very end of the file system (which would > avoid further fragmentation). Either way, it adds a lot more > complications, and realistically, have you ever actually seen a user > take advantage of a backup superblock other than the one at block > #32768? > > Still, it is something we could do, if we really thought it would > help. My original thought was that keeping things simple was better > than adding more complexity, especially if the vast majority of users > would never take advantage of such a feature, and given that everyone > is trained to know that a backup superblock is always available at > 32768, so we really want to have one there regardless. Given that, is > having a third backup superblock at the end of the disk really going > to provide that much additional safety? > I agree with you here, after being worked as a frontline support for a few years, I guess I became too paranoid :) The first thing that came to my mind when you argued about removing remaining backup superblocks was about people issuing `dd` commands to wrong places of the device, and having a copy at the very end of the filesystem is less feasible of somebody rewrite it than at the beginning (or even at 32768). But as I said, I agree with you here, too much time I don't see anybody needing other backup SB. > -Ted > > P.S. If we want to have extra copies of the backup blocks, we could > also use e2image to make additional backup copies; we could even a > future version of mke2fs place a copy of the e2image file at the very > of the file system, if we really thought it would be helpful later on. > If we thought it was really required, we should do it now, of course. > I'm just not entirely sure it's worth the extra hair, either way. I'm > curious to hear what other people think. > -- > 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 -- Carlos -- 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
