Hi Kautuk, On Fri, Aug 19, 2011 at 12:25:58AM +0800, Kautuk Consul wrote: > > Lines: 59 > > Hi Wu, > > On Thu, Aug 18, 2011 at 6:43 PM, Wu Fengguang <fengguang.wu@xxxxxxxxx> wrote: > > Hi Artem, > > > >> Here is a real use-case we had when developing the N900 phone. We had > >> internal flash and external microSD slot. Internal flash is soldered in > >> and cannot be removed by the user. MicroSD, in contrast, can be removed > >> by the user. > >> > >> For the internal flash we wanted long intervals and relaxed limits to > >> gain better performance. > >> > >> For MicroSD we wanted very short intervals and tough limits to make sure > >> that if the user suddenly removes his microSD (users do this all the > >> time) - we do not lose data. > > > > Thinking twice about it, I find that the different requirements for > > interval flash/external microSD can also be solved by this scheme. > > > > Introduce a per-bdi dirty_background_time (and optionally dirty_time) > > as the counterpart of (and works in parallel to) global dirty[_background]_ratio, > > however with unit "milliseconds worth of data". > > > > The per-bdi dirty_background_time will be set low for external microSD > > and high for internal flash. Then you get timely writeouts for microSD > > and reasonably delayed writes for internal flash (controllable by the > > global dirty_expire_centisecs). > > > > The dirty_background_time will actually work more reliable than > > dirty_expire_centisecs because it will checked immediately after the > > application dirties more pages. And the dirty_time could provide > > strong data integrity guarantee -- much stronger than > > dirty_expire_centisecs -- if used. > > > > Does that sound reasonable? > > > > Thanks, > > Fengguang > > > > My understanding of your email appears that you are agreeing in > principle that the temporal > aspect of this problem needs to be addressed along with your spatial > pattern analysis technique. Yup. > I feel a more generic solution to the problem is required because the > problem faced by Artem can appear > in a different situation for a different application. > > I can re-implement my original patch in either centiseconds or > milliseconds as suggested by you. My concern on your patch is the possible conflicts and confusions between the global and the per-bdi dirty_expire_centisecs. To maintain compatibility you need to keep the global one. Then there is the hard question of "what to do with the per-bdi values when the global value is changed". Whatever policy you choose, there will be user unexpected behaviors. I don't like such conflicting/inconsistent interfaces. Given that we'll need to introduce the dirty_background_time interface anyway, and it happen to can address the N900 internal/removable storage problem (mostly), I'm more than glad to cancel the dirty_expire_centisecs problem. Or, do you have better way out of the dirty_expire_centisecs dilemma? Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
