Messages in this thread | | | Date | Tue, 2 Jun 2020 13:53:38 +0200 | From | Boris Brezillon <> | Subject | Re: [PATCH v6 0/5] Micron SLC NAND filling block |
| |
On Tue, 02 Jun 2020 10:59:46 +0200 Bean Huo <huobean@gmail.com> wrote:
> On Tue, 2020-06-02 at 09:48 +0200, Boris Brezillon wrote: > > Hi Bean, > > > > On Mon, 01 Jun 2020 23:10:43 +0200 > > Bean Huo <huobean@gmail.com> wrote: > > > > > Hi Richard > > > would you please help us confirm below question?? > > > > Miquel suggested an approach that would allow us to deal with both > > JFFS2 > > and UBI/UBIFS without having any FS/wear-leveling specific code at > > the > > NAND level, but you decided to ignore his comments. Sorry but there's > > nothing we can do to help you if you don't listen to our > > recommendations. > > Expose this issue to FS layer, it is not good idea. that will impact > more code, and involve duplicated code.
Sorry but as far as I'm concerned, you've lost the right to have your word in such design choices a long time ago. You can't deliberately lie to us for several weeks/months and expect us to trust you (your judgment) after that.
Back to the actual proposal, it's something that came from a discussion we had with Miquel and Richard. It's certainly not perfect, but neither is the option of hardcoding a quirk for JFFS2/UBI/UBIFS in the Micron NAND driver.
BTW, I think you completely occluded Miquel's suggestion to have a generic implementation at the MTD level for users who don't care about the pattern that's written to those 'soon-to-be-erased' blocks. See, that's one of the things I'm complaining about. You seem to ignore (don't know if it's deliberate or not) some of the suggestions we do.
> > > > I've been quite disappointed by your behavior in the past, and it > > > continues. Recently you've taken Miquel's patches and claimed > > ownership > did you seem my recent patch? you can ignore that see this.
I don't understand what you mean here, sorry.
> > > > on them (probably not intentionally, but still) while you were > > clearly > > unable to rework your original series the way I suggested (which > > Miquel > > did after seeing you would never send new versions). > > seriously?
Yes, seriously!
> > > And when Miquel > > suggested a change to the implementation he had done based on the > > discussion we had with Richard, you decided to ignore it and pursue > > in > > the original direction. So, quite frankly, I'm really not convinced > > you > > can conduct such a change. > > > > As Miquel mentioned, we need richard's final comfirmation, > If he agrees with this proposal, I give up my current patch. >
Actually, you need more than Richard's blessing. Miquel has to agree on the NAND changes, and even if I can't block the solution, I think I can at least give my opinion: anything that involves FS/wear-leveling specific code at the NAND level should be avoided. Given the discussion we had regarding JFFS2 and the cleanmarkers, I don't think we can come up with a solution that's safe for every users, hence the proposal to empower users with this responsibility.
| |