-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/22/15 9:36 AM, Holger Hoffstätte wrote: > 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!
Ok, say you have a file system populated entirely with ~ 3k files. You won't actually need a data chunk at all and you'd just waste that chunk. A file system like that wouldn't need a data chunk at all. It's a contrived case, sure, but not an unrealistic one. We've already seen workloads like this. >> 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. :) The simplest way would be to add a flag to disallow removal of block groups. If the goal is to say "this device is only to be used for metadata at X RAID level" then it's enough to say that chunks on that device can't be balanced away. Beyond that, we start to run into the same problems we have with RAID levels now. The disk format technically supports multiple RAID levels simultaneously for both data and metadata. How that would work in practice gets a little tricky. Maybe, as David said, something like object properties are the answer. If a subvolume is annotated as needing storage of a particular description, then we can create chunks meeting that requirement as required. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJWAYB0AAoJEB57S2MheeWyrjcP/2tnnrkV3Ghxpr5rglfiPEDB ma2OS17FJHkWcPAGlw/KMsxXxU2UX8QNuX9R39Dp+seWprplMPMQQqD12dMZGd9M 4ZeXcv6AzSWW+aE3O1cnXZK4sJMHkb+t5Tk4nRBHY+wf9VIy1bBWwbnfde8jbau0 WubvjDQeCM4AjMbKOhqTsfWtCNXv6pbPzrBI070JQkIvLyvDNVNQ37XQ76The1tW W/urZecv0Efw9fXruGZcvXPKkUOuc/Fh6xsWBQyDqjU0EDx9TyX27ZCSLYmPON6E Ihlk3BY96TV8AeFH0IAbFyWfaYL4pokPF+hW06hjPSgMBOEE8NKnL1SyLFU7xNTt pcQ7KISxGPvLiNyeN0ESDU7WoifmEO0wr/dNSKd4iFJxRi9pImKYViscgNTkPmAt hkFNKANGTwa7/YBXYVwctfYbSdF0DFHakvG4PTtiucjTW04BhIlU8UC/eUqGbpol CRQZY/JPy80Sgc/dNktY3srMfgeWhcu7E+Q6ogS4LQ//5ry1NlxB34nTMVEdjR5v yivkvxjMXZHKxC8CBOF5xDP7ILq5Zf9m+mozjnEI6flto72t4N6TB70Zwj3+3mSw vG3k/kZCqSF6tfNoPUibOuLpZsA9KVpTMtZfU6niOSOuvPBZHyjwR6ErtZoQt+VJ jL+GQMaHE28HjEQ2z64D =9oFr -----END PGP SIGNATURE----- -- 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