On Sat, 2013-09-28 at 15:55 +0200, Richard Weinberger wrote:
> this series is a collection of all pending UBI fastmap updates.
>
> Richard Genoud found issues in combination with U-Boot.
> These issues also uncovered other minor issues in some error paths.
> Only one fix is not really fastmap spec
On Fri, 2012-08-17 at 15:43 +0200, Richard Weinberger wrote:
> No, data is never added to a half-filled PEB.
OK.
> Fastmap does not share PEBs with other sub-systems by design.
It could in theory add own data to own PEBs.
--
Best Regards,
Artem Bityutskiy
signature.asc
Description: This is a
Am Fri, 17 Aug 2012 16:41:24 +0300
schrieb Artem Bityutskiy :
> On Fri, 2012-08-17 at 15:33 +0200, Richard Weinberger wrote:
> > Am Fri, 17 Aug 2012 16:11:55 +0300
> > schrieb Artem Bityutskiy :
> > > We do not do anything like this in UBI because UBI does not need
> > > this, it does not have any
On Fri, 2012-08-17 at 15:33 +0200, Richard Weinberger wrote:
> Am Fri, 17 Aug 2012 16:11:55 +0300
> schrieb Artem Bityutskiy :
> > We do not do anything like this in UBI because UBI does not need this,
> > it does not have any complex data structures on the media.
> >
> > With fastmap - I am unsur
Am Fri, 17 Aug 2012 16:11:55 +0300
schrieb Artem Bityutskiy :
> We do not do anything like this in UBI because UBI does not need this,
> it does not have any complex data structures on the media.
>
> With fastmap - I am unsure. I think it is not a problem, because
> probably you never append more
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
> This is the next round of UBI fastmap updates.
> It fixes all issues pointed out by Shmulik. :-)
>
> If you want to test fastmap you can use my git repo:
> git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubi2.git ubi2/v17
One thing w
On Tue, 2012-08-07 at 09:29 +0200, Richard Weinberger wrote:
> Am 07.08.2012 06:21, schrieb Artem Bityutskiy:
> > On Mon, 2012-08-06 at 19:36 +0200, Richard Weinberger wrote:
> >> I think we enable fastmap only if a MTD device has more than
> >> UBI_FM_MAX_START*2 PEBs.
> >> Any comments?
> >
> >
Am 07.08.2012 06:21, schrieb Artem Bityutskiy:
> On Mon, 2012-08-06 at 19:36 +0200, Richard Weinberger wrote:
>> I think we enable fastmap only if a MTD device has more than
>> UBI_FM_MAX_START*2 PEBs.
>> Any comments?
>
> With double space one can make it power-cut tolerant, because you should
>
On Mon, 2012-08-06 at 19:36 +0200, Richard Weinberger wrote:
> I think we enable fastmap only if a MTD device has more than
> UBI_FM_MAX_START*2 PEBs.
> Any comments?
With double space one can make it power-cut tolerant, because you should
be able to have either old or new fastmap at any point of
Am 02.08.2012 16:58, schrieb Artem Bityutskiy:
> On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
>> This is the next round of UBI fastmap updates.
>> It fixes all issues pointed out by Shmulik. :-)
>
> Hi Richard,
>
> when I try to attach mtdram (NOR flash), UBI fails:
Fastmap works
Am 05.08.2012 10:23, schrieb Shmulik Ladkani:
> On Thu, 2 Aug 2012 19:45:38 +0200 Richard Weinberger wrote:
>> Okay, then let's explicitly reserve a few PEBs for fastmap.
>> This should be very easy task.
>
> Need to consider what's expected when migrating from a former non-FM
> UBI system to an
Hi,
On Thu, 2 Aug 2012 19:45:38 +0200 Richard Weinberger wrote:
> Okay, then let's explicitly reserve a few PEBs for fastmap.
> This should be very easy task.
Need to consider what's expected when migrating from a former non-FM
UBI system to an FM enabled system, in the case where all PEBs where
Am Fri, 03 Aug 2012 11:47:17 +0300
schrieb Artem Bityutskiy :
> On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
> > This is the next round of UBI fastmap updates.
> > It fixes all issues pointed out by Shmulik. :-)
> >
> > If you want to test fastmap you can use my git repo:
> > git:
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
> This is the next round of UBI fastmap updates.
> It fixes all issues pointed out by Shmulik. :-)
>
> If you want to test fastmap you can use my git repo:
> git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubi2.git ubi2/v17
Richard,
I
On Thu, 2012-08-02 at 21:50 +0300, Artem Bityutskiy wrote:
> On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
> > This is the next round of UBI fastmap updates.
> > It fixes all issues pointed out by Shmulik. :-)
> >
> > If you want to test fastmap you can use my git repo:
> > git://gi
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
> This is the next round of UBI fastmap updates.
> It fixes all issues pointed out by Shmulik. :-)
>
> If you want to test fastmap you can use my git repo:
> git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubi2.git ubi2/v17
Richard, wo
On Thu, 2012-08-02 at 20:03 +0200, Richard Weinberger wrote:
> > If I understand correctly, fastmap size is a function of total PEBs
> > count. You should be able to calculate the maximum size precisely.
>
> It does.
> I was thinking of 2 x sizeof(fastmap) to have reserved PEBs for the
> currently
Am Thu, 02 Aug 2012 20:59:28 +0300
schrieb Artem Bityutskiy :
> > How much PEB should be reserved? 2 x sizeof(fastmap)?
>
> Is there any reason why it cannot be the _exact_ maximum number? Not
> more and not less.
The fastmap size is an exact number.
> If I understand correctly, fastmap size
On Thu, 2012-08-02 at 19:45 +0200, Richard Weinberger wrote:
> This should be very easy task.
Right. But unfortunately, I had to spend a lot of time writing lengthy
e-mails. You could hold your horses for a minute, ask specific questions
and find out what was my concern.
> How much PEB should be
On Thu, 2012-08-02 at 10:03 -0700, Tim Bird wrote:
> > So can I interpret this the following way. Not only fastmap give no
> > guarantees that it exists after an unclean reboot, it does not even give
> > guarantees that it exists after a clean reboot.
> >
> > Unless I am confused, the fastmap desi
Am Thu, 02 Aug 2012 20:40:00 +0300
schrieb Artem Bityutskiy :
> Hi Tim,
>
> On Thu, 2012-08-02 at 10:03 -0700, Tim Bird wrote:
> > I'm don't understand what "UBI liability" is. Can you please
> > clarify? What breaks if the PEBs get consumed?
>
> let me try. Let's forget about bad blocks and as
Hi Tim,
On Thu, 2012-08-02 at 10:03 -0700, Tim Bird wrote:
> I'm don't understand what "UBI liability" is. Can you please clarify?
> What breaks if the PEBs get consumed?
let me try. Let's forget about bad blocks and assume we are talking
about NOR flash. For simplicity.
Let's also first forget
Am Thu, 2 Aug 2012 10:03:04 -0700
schrieb Tim Bird :
> >> If everything goes wrong, fastmap makes sure that no fastmap is on
> >> flash.
> >> In case of a powercut we fall back to scanning mode.
> >> R/O mode is overkill IMHO.
> >
> > So can I interpret this the following way. Not only fastmap giv
On 08/02/2012 09:45 AM, Artem Bityutskiy wrote:
> Richard,
>
> On Thu, 2012-08-02 at 18:32 +0200, Richard Weinberger wrote:
>>> This should not happen. Fastmap should _reserve_ enough of PEBs for it
>>> to operate. It should always find the PEB to write.
>>
>> What is the benefit?
>> IOW what is w
Am Thu, 02 Aug 2012 19:45:30 +0300
schrieb Artem Bityutskiy :
> Richard,
>
> On Thu, 2012-08-02 at 18:32 +0200, Richard Weinberger wrote:
> > > This should not happen. Fastmap should _reserve_ enough of PEBs
> > > for it to operate. It should always find the PEB to write.
> >
> > What is the ben
Richard,
On Thu, 2012-08-02 at 18:32 +0200, Richard Weinberger wrote:
> > This should not happen. Fastmap should _reserve_ enough of PEBs for it
> > to operate. It should always find the PEB to write.
>
> What is the benefit?
> IOW what is wrong with the current approach?
Several reasons. The ma
Am Thu, 02 Aug 2012 19:17:47 +0300
schrieb Artem Bityutskiy :
> On Thu, 2012-08-02 at 16:51 +0200, Richard Weinberger wrote:
> > Every time fastmap writes a new fastmap to the flash it tries to
> > get a new PEB and returns the old one (used for the old fastmap)
> > back to the WL sub-system.
>
>
On Thu, 2012-08-02 at 16:51 +0200, Richard Weinberger wrote:
> Every time fastmap writes a new fastmap to the flash it tries to get a
> new PEB and returns the old one (used for the old fastmap) back to the
> WL sub-system.
OK.
> If no free PEBs are available (E.g Volume is full or the erase work
Am Thu, 02 Aug 2012 18:18:48 +0300
schrieb Artem Bityutskiy :
> > Hmm, and without fastmap it works fine?
>
> Yes.
>
> > I don't see much fastmap related here.
>
> It is related to your changes in attach.c.
Okay, I'll dig into the issue.
Thanks,
//richard
--
To unsubscribe from this list: send
On Thu, 2012-08-02 at 16:59 +0200, Richard Weinberger wrote:
> Am Thu, 02 Aug 2012 17:58:50 +0300
> schrieb Artem Bityutskiy :
>
> > On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
> > > This is the next round of UBI fastmap updates.
> > > It fixes all issues pointed out by Shmulik. :
Am Thu, 02 Aug 2012 17:58:50 +0300
schrieb Artem Bityutskiy :
> On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
> > This is the next round of UBI fastmap updates.
> > It fixes all issues pointed out by Shmulik. :-)
>
> Hi Richard,
>
> when I try to attach mtdram (NOR flash), UBI fai
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
> This is the next round of UBI fastmap updates.
> It fixes all issues pointed out by Shmulik. :-)
Hi Richard,
when I try to attach mtdram (NOR flash), UBI fails:
[ 7106.353791] UBI assert failed in ubi_io_is_bad at 623 (pid 5411)
[ 71
Am Thu, 02 Aug 2012 17:29:01 +0300
schrieb Artem Bityutskiy :
> On Thu, 2012-08-02 at 16:15 +0200, Richard Weinberger wrote:
> > > If I understand correctly, it can be only because of a bug. If I
> > > am correct, could you please add a 'dump_stack()' to improve the
> > > error report?
> > >
> >
On Thu, 2012-08-02 at 16:15 +0200, Richard Weinberger wrote:
> > If I understand correctly, it can be only because of a bug. If I am
> > correct, could you please add a 'dump_stack()' to improve the error
> > report?
> >
>
> This can happen if all PEBs are used and fastmap is unable to find (or
>
Artem,
Am Thu, 02 Aug 2012 17:12:27 +0300
schrieb Artem Bityutskiy :
> On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
> > This is the next round of UBI fastmap updates.
> > It fixes all issues pointed out by Shmulik. :-)
>
> I see the following errors when rung UBI tests on nandsim
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
> This is the next round of UBI fastmap updates.
> It fixes all issues pointed out by Shmulik. :-)
I see the following errors when rung UBI tests on nandsim:
[ 3698.041511] UBI error: __wl_get_peb: no free eraseblocks
[ 3698.041781] UBI
Am 09.07.2012 09:37, schrieb Shmulik Ladkani:
> Hi Richard,
>
> On Sun, 08 Jul 2012 14:07:41 +0200 Richard Weinberger wrote:
>>> + /* TODO: in the new locking scheme, produce_free_peb is
>>> +* called under wl_lock taken.
>>> +* so when re
Hi Richard,
On Sun, 08 Jul 2012 14:07:41 +0200 Richard Weinberger wrote:
> > + /* TODO: in the new locking scheme, produce_free_peb is
> > +* called under wl_lock taken.
> > +* so when returning, should reacquire the lock
> > +
Am 08.07.2012 14:07, schrieb Richard Weinberger:
> Hi Shmulik!
>
> Am 08.07.2012 13:47, schrieb Shmulik Ladkani:
>> +
>> +/* TODO: if find_fastmap==1, we do not enter this block at all.
>> + * shouldn't we? shouldn't we care of compatability of unknown
>> + * in
Hi Shmulik!
Am 08.07.2012 13:47, schrieb Shmulik Ladkani:
> +
> + /* TODO: if find_fastmap==1, we do not enter this block at all.
> + * shouldn't we? shouldn't we care of compatability of unknown
> + * internal volumes OTHER than the fastmap ones, even if
> +
Hi Richard,
On Fri, 29 Jun 2012 17:14:18 +0200 Richard Weinberger wrote:
> This is the next round of UBI fastmap updates.
Please examine some TODOs (and questions) I've spotted while diffing
against "vanilla" ubi.
This patch should apply to linux-ubi at d41a140
Sorry I couldn't review entirely
41 matches
Mail list logo
