On Thu, Aug 18, 2016 at 03:26:58PM +0200, David Sterba wrote: > On Thu, Jul 28, 2016 at 11:42:55AM -0400, Sanidhya Solanki wrote: > > > I'll comment on the overall approach and skip code-specific comments. > > > > > > The changelog does not explain why there's a need for a new blockgroup > > > type and what's the relation to the existing types. It seems that it > > > extends the data/metadata/system group, but I think this is totally > > > wrong. > > > > I agree in principle, but I did not want to modify the existing balance > > targets, but, instead, piggyback on the existing balance implementation > > to re-balance the data. > > But this is not about balance. The stripe size is more like node size, > ie. something that gets set at the mkfs time and stays for the > filesystem lifetime. Multiple stripesize values would be hard to > implement at least, not something that we'd do for the first > implementation. > > > This approach was recommended to be by an experienced BTrFS developer > > on the IRC as the right way to implement the change. > > I want his name. I remember talking to you about that patch but > dismissed the 'another raid group' approach.
It may have been me. I pointed out that the idea as initially presented, simply changing the global value on an existing FS (at runtime, no less!), would break the FS badly if you wanted to be able to convert from one size to another at runtime (because when you change the value, you immediately invalidate the existing on-disk data, and your data gets... interestingly rearranged). I said that the approach I'd take would be to add the stripe size as a parameter to the block group, so that BGs know their own stripe size. Then implement a balance filter so that you can read a BG (in the old stripe size, which it knows about), and write a new BG with the new stripe size and the old data (now restriped). It was a long and somewhat struggling conversation, and I may not have got the point across very well. Hugo. -- Hugo Mills | If the first-ever performance is the première, is hugo@... carfax.org.uk | the last-ever performance the derrière? http://carfax.org.uk/ | PGP: E2AB1DE4 |
signature.asc
Description: Digital signature
