On 09/22/15 14:59, Jeff Mahoney wrote: (snip) > So if they way we want to prevent the loss of raid type info is by > maintaining the last block group allocated with that raid type, fine, > but that's a separate discussion. Personally, I think keeping 1GB
At this point I'm much more surprised to learn that the RAID type can apparently get "lost" in the first place, and is not persisted separately. I mean..wat? > allocated as a placeholder is a bit much. Beyond that, I've been Can you explain why keeping at least one data chunk (or the appropriate number across devices, depending on RAID level..) is "a bit much"? IMHO this would have no real negative impact on end users (who think in terms of overall filesystem space, not how much of that has been lazily touched), nor for more obscure use cases like sparse images - which would still be sparsely reserved. So there would not be any actual downside that I can see. From a fs consistency point of view it sounds much more sane to assume that at least a basic set of data chunks always need to exist. I know I was very surprised recently to see all my data chunks cleaned up on an otherwise empty fs. I mean..it's good to see that the house cleaning works, but you also gotta know when to stop! > thinking casually about ways to direct the allocator to use certain > devices for certain things (e.g. in a hybrid system with SSDs and > HDDs, always allocate metadata on the SSD) and there's some overlap > there. As it stands, we can fake that in mkfs but it'll get stomped > by balance nearly immediately. Please share those casual thoughts with the group. :) -h -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
