On 06/02/2017 05:45 AM, Vladimir Sementsov-Ogievskiy wrote: > 02.06.2017 12:01, Vladimir Sementsov-Ogievskiy wrote: >> 02.06.2017 11:56, Vladimir Sementsov-Ogievskiy wrote: >>> 02.06.2017 02:25, John Snow wrote: >>>> >>>> On 06/01/2017 03:30 AM, Sementsov-Ogievskiy Vladimir wrote: >>>>> Hi John! >>>>> >>>>> Look at our discussion about this in v18 thread. >>>>>> Shortly: readonly is not the same as disabled. disabled= bitmap just >>>>> ignores all writes. readonly= writes are not allowed at all. >>>>> >>>>> And I think, I'll try to go through way 2: "dirty" field instead of >>>>> "readonly" (look at v18 discussion), as it a bit more flexible. >>>>> >>>> Not sure which I prefer... >>>> >>>> Method 1 is attractive in that it is fairly simple, and enforces fairly >>>> loudly the inability to write to devices with RO bitmaps. It's a >>>> natural >>>> extension of your current approach. >>> >>> For now I decided to realize this one, I think I'll publish it today. >>> Also, I'm going to rename s/readonly/in_use - to avoid the confuse >>> with disabled. So let this field just be mirror of IN_USE in the >>> image and just say "persistent storage knows, that bitmap is in use >>> and may be dirty". > > Finally it would be readonly. in_use is bad for created (not loaded) > bitmaps. I'll add more descriptive comments for disabled and readonly. >
Makes sense. It sounds like "readonly" is simply a stricter superset of "disabled," where "disabled" doesn't care if the bitmap gets out of sync with the data, but "readonly" attempts to preserve that semantic relationship. >>> >>> Also, optimization with 'dirty' flag may be added later. >> Yes, I agree. >> And, also, I don't want to influence this "first write", on which we >> will set "IN_USE" in all bitmaps (for way (2). Reopening rw is less >> performance-demanding place than write. >> "And, also," -- I think you've been reading my emails too much, you're picking up my 'isms ;) Thanks, --John