UBI: io_write_path

UBI: io_write_path

[brijesh.singh]

Hi,
   I walked through eba_write path.I found that,if EBUSY or EAGAIN is
returned as err code from ubi_io_write_vid_hdr or ubi_io_write_data
,still the PEB is put back to wear-levelling.This is
unnecessary.Shouldn't it retry on same PEB again?
Code Snip:
----------------------------------------------------------------------------
retry:
	pnum = ubi_wl_get_peb(ubi, dtype);
	if (pnum < 0) {
		ubi_free_vid_hdr(ubi, vid_hdr);
		leb_write_unlock(ubi, vol_id, lnum);
		return pnum;
	}

	err = ubi_io_write_vid_hdr(ubi, pnum, vid_hdr);
	if (err) {
		ubi_warn("failed to write VID header to LEB %d:%d, PEB %d",
			 vol_id, lnum, pnum);
		goto write_error;
	}

	err = ubi_io_write_data(ubi, buf, pnum, offset, len);
	if (err) {
		ubi_warn("failed to write %d bytes at offset %d of LEB %d:%d, " "PEB
%d", len, offset, vol_id, lnum, pnum);
		goto write_error;
	}
...

write_error:
	if (err != -EIO || !ubi->bad_allowed) {
		ubi_ro_mode(ubi);
		leb_write_unlock(ubi, vol_id, lnum);
		ubi_free_vid_hdr(ubi, vid_hdr);
		return err;
	}

	/*
	 * Fortunately, this is the first write operation to this physical
	 * eraseblock, so just put it and request a new one. We assume that if
	 * this physical eraseblock went bad, the erase code will handle that.
	 */
	err = ubi_wl_put_peb(ubi, pnum, 1);
	if (err || ++tries > UBI_IO_RETRIES) {
		ubi_ro_mode(ubi);
		leb_write_unlock(ubi, vol_id, lnum);
		ubi_free_vid_hdr(ubi, vid_hdr);
		return err;
	}

	vid_hdr->sqnum = cpu_to_be64(next_sqnum(ubi));
	ubi_msg("try another PEB");
	goto retry;

-------------------------------------------------------------------------
Regards,
Brijesh

Re: UBI: io_write_path

[Artem Bityutskiy]

Hi,

On Thu, 2007-07-12 at 16:01 +0530, brijesh.singh@calsoftinc.com wrote:
> Hi,
>    I walked through eba_write path.I found that,if EBUSY or EAGAIN is
> returned as err code from ubi_io_write_vid_hdr or ubi_io_write_data
> ,still the PEB is put back to wear-levelling.This is
> unnecessary.Shouldn't it retry on same PEB again?

AFAICS if any error except -EIO is returned, we just return it up (see
below)

Probably you are right, -EBUSY and -EAGAIN could be treated differently.
We could put this LEB and try a new one. But we cannot try the same one
I guess, at least it does not sound safe. Who knows, may be something
was written? It is safer to take a new PEB. But yes, it is not
necessarily to torture this LEB in case of -EBUSY and -EAGAIN.

Feel free to send a patch. It would be also nice if you pointed when MTD
could return these errors, because I doubt it is possible in current
implementation. But anyways, handling those gracefully is good.


> Code Snip:
> ----------------------------------------------------------------------------
> retry:
> 	pnum = ubi_wl_get_peb(ubi, dtype);
> 	if (pnum < 0) {
> 		ubi_free_vid_hdr(ubi, vid_hdr);
> 		leb_write_unlock(ubi, vol_id, lnum);
> 		return pnum;
> 	}
> 
> 	err = ubi_io_write_vid_hdr(ubi, pnum, vid_hdr);
> 	if (err) {
> 		ubi_warn("failed to write VID header to LEB %d:%d, PEB %d",
> 			 vol_id, lnum, pnum);
> 		goto write_error;
> 	}
> 
> 	err = ubi_io_write_data(ubi, buf, pnum, offset, len);
> 	if (err) {
> 		ubi_warn("failed to write %d bytes at offset %d of LEB %d:%d, " "PEB
> %d", len, offset, vol_id, lnum, pnum);
> 		goto write_error;
> 	}
> ...
> 
> write_error:
> 	if (err != -EIO || !ubi->bad_allowed) {
> 		ubi_ro_mode(ubi);
> 		leb_write_unlock(ubi, vol_id, lnum);
> 		ubi_free_vid_hdr(ubi, vid_hdr);
> 		return err;
> 	}

So here we switch to RO mode and return the error up. We could do
better. Like -ENOMEM should not cause switching to RO mode. -EAGAIN and
-EBUSY - similarly.

I bet there are other places where error handling could be smarter. Feel
free to send patches.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)