> > >
> > > Data integrity is much more important for us than speed.
> > >
> >
> >
> > You might want to consider ReiserFS or one of the others which were
> > designed with journaling in mind. And I hope you're using RAID1 or RAID5.
>
> We are using ext3 on a compact flash disk in an embedded device. So we
> are not using RAID systems.
[I'm not subscribed, hopefully this threads]
Um, is this a new application or have you done this before?
It's my understanding that very few (or no) CF devices do wear-levelling internally.
Using a journal, especially a true data journal, seems like *the* way to wear out your
flash as quickly as possible.
If you've had success using ext2 in read/write mode on flash/CF in a shipping product,
I for one would like to know more details!
ken
Doesn't Reiser4 do wear-leveling for flash?
Ken Ryan wrote:
>> > > > > Data integrity is much more important for us than speed.
>> > > > > > You might want to consider ReiserFS or one of the others
>> which were > designed with journaling in mind. And I hope you're
>> using RAID1 or RAID5.
>>
>> We are using ext3 on a compact flash disk in an embedded device. So we
>> are not using RAID systems.
>
>
> [I'm not subscribed, hopefully this threads]
>
> Um, is this a new application or have you done this before?
>
> It's my understanding that very few (or no) CF devices do wear-levelling
> internally.
> Using a journal, especially a true data journal, seems like *the* way to
> wear out your
> flash as quickly as possible.
>
> If you've had success using ext2 in read/write mode on flash/CF in a
> shipping product,
> I for one would like to know more details!
>
> ken
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
Timothy Miller wrote:
> Doesn't Reiser4 do wear-leveling for flash?
No, we don't. We do have wandering logs, so it would be feasible to
code, but bitmap blocks and super blocks get written to the same
locations repeatedly.
Actually, most compact flash devices DO do wear leveling, from what I
have heard.
>
> Ken Ryan wrote:
>
>>> > > > > Data integrity is much more important for us than speed.
>>> > > > > > You might want to consider ReiserFS or one of the others
>>> which were > designed with journaling in mind. And I hope you're
>>> using RAID1 or RAID5.
>>>
>>> We are using ext3 on a compact flash disk in an embedded device. So we
>>> are not using RAID systems.
>>
>>
>>
>> [I'm not subscribed, hopefully this threads]
>>
>> Um, is this a new application or have you done this before?
>>
>> It's my understanding that very few (or no) CF devices do
>> wear-levelling internally.
>> Using a journal, especially a true data journal, seems like *the* way
>> to wear out your
>> flash as quickly as possible.
>>
>> If you've had success using ext2 in read/write mode on flash/CF in a
>> shipping product,
>> I for one would like to know more details!
>>
>> ken
>>
>>
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-kernel" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>>
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
Hans Reiser wrote:
> Timothy Miller wrote:
>
>> Doesn't Reiser4 do wear-leveling for flash?
>
>
> No, we don't. We do have wandering logs, so it would be feasible to
> code, but bitmap blocks and super blocks get written to the same
> locations repeatedly.
>
> Actually, most compact flash devices DO do wear leveling, from what I
> have heard.
The ones I've seen, only sort of. They'll allocate writes from
available erased pages to try to distribute their use, but if you
have a disk that's, say, 70% read-only data and 30% read-write then the
wear-levelling will only happen on that
30% of the disk. True wear levelling will actually scrub read-only or
rarely-written data, forcing it to get off its
duff so the flash cells they're sitting on can get some exercise, and
give the more worn cells a rest (that scrub
helps ECC fix soft errors from weak cells too). True wear-levelling is
really hard, and obviously requires
budgeting extra bandwidth and storage devices for safely shuffling
around data that the application has no
intention of moving (picture losing power in the middle of a scrub).
It's not worth it for the consumer CF
usage model of "take photos until the card is full, then copy them all
to the PC and wipe the card clean".
[Yes, I tend to see this from the inside-out: I'm actually an FPGA/ASIC
weenie not a kernel hacker. One of my current
projects is part of a controller chip for a solid-state storage system
with ${bignum} NAND flash chips. Alas, my specialty
is video and graphics, so I'm still coming up the learning curve on
storage systems].
ken
On 17.06.2004, at 19:20, Hans Reiser wrote:
> Actually, most compact flash devices DO do wear leveling, from what I
> have heard.
Care to mention sources? I'd be surprised if they did simply because
it'll cost money that could be earned otherwise. Also I think you
confuse bad block remapping with wear leveling and even the former
I haven't experienced so far.
CF disks were designed for simply the reason of having an empty disk,
writing data onto it up to a certain level, reading it a few times
and emptying the disk again. So except for the organizational blocks
and "the end" of a disk which tends to get rarely hit there're a
well distributed write utilization.
Servus,
Daniel
Daniel Egger wrote:
> On 17.06.2004, at 19:20, Hans Reiser wrote:
>
>> Actually, most compact flash devices DO do wear leveling, from what I
>> have heard.
>
>
> Care to mention sources? I'd be surprised if they did simply because
> it'll cost money that could be earned otherwise. Also I think you
> confuse bad block remapping with wear leveling and even the former
> I haven't experienced so far.
>
> CF disks were designed for simply the reason of having an empty disk,
> writing data onto it up to a certain level, reading it a few times
> and emptying the disk again. So except for the organizational blocks
> and "the end" of a disk which tends to get rarely hit there're a
> well distributed write utilization.
>
> Servus,
> Daniel
For example:
Just bop over to the Sandisk website, go the the OEM section, and download
the manual/datasheet for CF devices. The wearlevel command itself isn't
supported (I'm ignorant of flash on IDE, I assume it is intended to mean
full scrub-style wear levelling) but they note they roll simplified wear
levelling
into the erased page pool.
Doing that is an easy way to get part of the way there without needing a
lot of
infrastructure. And for the fill-read-empty usage model it's perfectly
fine.
ken
Ken Ryan wrote:
> Hans Reiser wrote:
>
>> Timothy Miller wrote:
>>
>>> Doesn't Reiser4 do wear-leveling for flash?
>>
>>
>>
>> No, we don't. We do have wandering logs, so it would be feasible to
>> code, but bitmap blocks and super blocks get written to the same
>> locations repeatedly.
>>
>> Actually, most compact flash devices DO do wear leveling, from what I
>> have heard.
>
>
>
> The ones I've seen, only sort of. They'll allocate writes from
> available erased pages to try to distribute their use, but if you
> have a disk that's, say, 70% read-only data and 30% read-write then
> the wear-levelling will only happen on that
> 30% of the disk. True wear levelling will actually scrub read-only or
> rarely-written data, forcing it to get off its
> duff so the flash cells they're sitting on can get some exercise, and
> give the more worn cells a rest (that scrub
> helps ECC fix soft errors from weak cells too). True wear-levelling
> is really hard, and obviously requires
> budgeting extra bandwidth and storage devices for safely shuffling
> around data that the application has no
> intention of moving (picture losing power in the middle of a scrub).
> It's not worth it for the consumer CF
> usage model of "take photos until the card is full, then copy them all
> to the PC and wipe the card clean".
>
> [Yes, I tend to see this from the inside-out: I'm actually an
> FPGA/ASIC weenie not a kernel hacker. One of my current
> projects is part of a controller chip for a solid-state storage system
> with ${bignum} NAND flash chips. Alas, my specialty
> is video and graphics, so I'm still coming up the learning curve on
> storage systems].
>
> ken
>
>
>
>
>
Interesting. Thanks for educating me.
No existing general purpose filesystem that I know of will address your
needs. We could of course write one if someone paid for it....
> >
> > We are using ext3 on a compact flash disk in an embedded device. So we
> > are not using RAID systems.
>
> Um, is this a new application or have you done this before?
>
> It's my understanding that very few (or no) CF devices do wear-levelling internally.
> Using a journal, especially a true data journal, seems like *the* way to wear out your
> flash as quickly as possible.
>
> If you've had success using ext2 in read/write mode on flash/CF in a shipping product,
> I for one would like to know more details!
>
> ken
>From our data sheet:
Wear Leveling is an intrinsic part of the operation of
SanDisk products using NAND memory.
But for sure, we will use a Compact flash that DO wear leveling, and
also shuffling read-only data around the Compact Flash disk.
This will be for production, yes.
Petter