Messages in this thread | | | Subject | Re: [PATCH v2 0/3] md superblock write alignment on 512e devices | From | Xiao Ni <> | Date | Thu, 5 Nov 2020 11:29:58 +0800 |
| |
On 11/04/2020 04:12 AM, Chris Unkel wrote: > Hi Xiao, > > Thanks for the excellent feedback. Since bitmap_offset appears to be > a free-form field, it wasn't apparent to me that the bitmap never > starts within 4K of the bitmap. > > I don't think it's worth worrying about a logical block size that's > more than 4K here--from what I can see logical block size larger than > the usual 4K page isn't going to happen. > > I do think that it makes sense to handle the case where the physical > block size is more than 4K. I think what you propose works, but I > think in the physical block > MAX_SB_SIZE case it makes more sense to > align the superblock writes to the physical block size (as now) rather Is it a typo error? You want to say if physical block > MAX_SB_SIZE, it should align the superblock writes to logical block size? Because I see the comments below, your solution is to align to logical block size when physical block > MAX_SB_SIZE. > than rejecting the create/assemble. Mounting with the possible > performance hit seems like a better outcome for the user in that case > than refusing to assemble. > It's the same check that would have to be written to reject the > assembly in that case and so the code shouldn't really be any more > complex. > > So basically what I propose is: if the physical block size is no > larger than MAX_SB_SIZE, pad to that; otherwise pad to to > logical_block_size, that is, replace queue_logical_block_size() > with something equivalent to: > > queue_physical_block_size(...) > MAX_SB_SIZE ? > queue_logical_block_size(...) : queue_physical_block_size(...) > > which is simple, safe in all cases, doesn't reject any feasible > assembly, and generates aligned sb writes on all common current > devices (512n,4kn,512e.) > > What do you think? Yes, It's a nice solution :)
Regards Xiao
| |