Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SDcard wear leveling and translation layers (2014)

msreekan.com

Post reply on HN
Print view View original

11–20 of 72 posts

Re: SDcard wear leveling and translation layers (2014)

#11

Post by actionfromafar »

londons_explore wrote: post #9

I am really disappointed by SD card reliability. It seems even a little wear and the whole thing slows down massively and eventually throws read/write errors. I would like to see a card design which, instead of failing when there is flash wear, instead just gets smaller. For compatibility with existing OS's, that would take the form of a self-partition-resizing sd card. It would understand fat32, ext3, NTFS, afs etc,…

Is there any Linux compatible file system which will be mounted redundantly without any special mount options?

So that for instance a 64 gigabyte would have a filesystem with 32 gigabyte space but with a lot of redundancy?

I know there are many ways to achieve similar outcomes but all I know of relies on knowing beforehand how to mount the thing.

Re: SDcard wear leveling and translation layers (2014)

#12

Post by londons_explore »

actionfromafar wrote: post #11
londons_explore wrote: post #9

I am really disappointed by SD card reliability. It seems even a little wear and the whole thing slows down massively and eventually throws read/write errors. I would like to see a card design which, instead of failing when there is flash wear, instead just gets smaller. For compatibility with existing OS's, that would take the form of a self-partition-resizing sd card. It would understand fat32, ext3, NTFS, afs etc,…

Is there any Linux compatible file system which will be mounted redundantly without any special mount options? So that for instance a 64 gigabyte would have a filesystem with 32 gigabyte space but with a lot of redundancy? I know there are many ways to achieve similar outcomes but all I know of relies on knowing beforehand how to mount the thing.

Unfortunately because of the way the SD card - computer interface works, storing everything twice on the same card doesn't actually get you much more reliability.

The card is unaware of which bits of data are duplicates, and therefore can easily end up storing both copies of some data on areas of the physical flash that are weak - and this is even more likely considering they will probably be written around the same timestamp.

Re: SDcard wear leveling and translation layers (2014)

#13

Post by st_goliath »

michaelt wrote: post #10

> For example, lets consider that we wrote to the sector 1024 on the SDCARD, and this address got initially mapped to physical sector 1024 itself on flash. Later we overwrite the contents, but this time write cannot go to the same physical address because it needs to be erased before programmed again. Maybe someone here will know the answer to something I've been wondering for a while: When appending to a file with w…

Pages that are already written cannot be overwritten, at least not without a full block erase, so it has to do a remap to append data.

Directly logging to an SD card (i.e. lots of small writes) is the fastest way to destroy it.

Re: SDcard wear leveling and translation layers (2014)

#14

Post by vbezhenar »

actionfromafar wrote: post #11
londons_explore wrote: post #9

I am really disappointed by SD card reliability. It seems even a little wear and the whole thing slows down massively and eventually throws read/write errors. I would like to see a card design which, instead of failing when there is flash wear, instead just gets smaller. For compatibility with existing OS's, that would take the form of a self-partition-resizing sd card. It would understand fat32, ext3, NTFS, afs etc,…

Is there any Linux compatible file system which will be mounted redundantly without any special mount options? So that for instance a 64 gigabyte would have a filesystem with 32 gigabyte space but with a lot of redundancy? I know there are many ways to achieve similar outcomes but all I know of relies on knowing beforehand how to mount the thing.

mdraid? Create two partitions and build a raid on top of them. Or any of advanced filesystems with built-in raid capabilities like bcachefs, btrfs or zfs.

Re: SDcard wear leveling and translation layers (2014)

#15

Post by ssl-3 »

actionfromafar wrote: post #11
londons_explore wrote: post #9

I am really disappointed by SD card reliability. It seems even a little wear and the whole thing slows down massively and eventually throws read/write errors. I would like to see a card design which, instead of failing when there is flash wear, instead just gets smaller. For compatibility with existing OS's, that would take the form of a self-partition-resizing sd card. It would understand fat32, ext3, NTFS, afs etc,…

Is there any Linux compatible file system which will be mounted redundantly without any special mount options? So that for instance a 64 gigabyte would have a filesystem with 32 gigabyte space but with a lot of redundancy? I know there are many ways to achieve similar outcomes but all I know of relies on knowing beforehand how to mount the thing.

ZFS can do this. Just set copies=2 on a dataset, and it'll always keep 2 copies of everything written thenceforth (with ~twice the storage usage).

And since it's a dataset setting instead of a pool setting, it can be applied selectively on a storage device.

"Oh, those photos are also backed up to Google Photos. It's maybe not ideal, but it's a lot of data and not worth keeping 2 copies those locally, so I'll leave those at the default of copies=1. But the this collection of code and short stories and I've written? That's pretty important to me, and it's actually kind of small -- I'll set that as copies=2. Actually, maybe copies=3 would be even better..."

The setting will stick with it between machines/sessions/whatevers without further user input. Things with copies=2 get mounted the same way as anything else is with ZFS in a given environment.

ZFS already detects bitrot very well even with copies=1, but it can't fix bitrot with chechsums alone. With copies=2, it has a non-zero chance at actually fixing it (or at least being completely readable so the data can be transitioned to the next storage device, completely intact).

https://docs.oracle.com/cd/E19253-01/819-5461/gevpg/index.ht...

Re: SDcard wear leveling and translation layers (2014)

#16

Post by ssl-3 »

vbezhenar wrote: post #14
actionfromafar wrote: post #11

Earlier quoted context omitted.

Is there any Linux compatible file system which will be mounted redundantly without any special mount options? So that for instance a 64 gigabyte would have a filesystem with 32 gigabyte space but with a lot of redundancy? I know there are many ways to achieve similar outcomes but all I know of relies on knowing beforehand how to mount the thing.

mdraid? Create two partitions and build a raid on top of them. Or any of advanced filesystems with built-in raid capabilities like bcachefs, btrfs or zfs.

Using mdraid requires special considerations when mounting in the future, doesn't it?

Re: SDcard wear leveling and translation layers (2014)

#17

Post by michaelt »

st_goliath wrote: post #13
michaelt wrote: post #10

> For example, lets consider that we wrote to the sector 1024 on the SDCARD, and this address got initially mapped to physical sector 1024 itself on flash. Later we overwrite the contents, but this time write cannot go to the same physical address because it needs to be erased before programmed again. Maybe someone here will know the answer to something I've been wondering for a while: When appending to a file with w…

Pages that are already written cannot be overwritten, at least not without a full block erase, so it has to do a remap to append data. Directly logging to an SD card (i.e. lots of small writes) is the fastest way to destroy it.

As I understand it, you need a block erase to change bits from 0 to 1 then you can selectively set bits back from 1 to 0.

Couldn't you perform a file append without the need for a block erase? By keeping the unwritten area as all ones until written?

Re: SDcard wear leveling and translation layers (2014)

#18

Post by st_goliath »

michaelt wrote: post #17
st_goliath wrote: post #13

Earlier quoted context omitted.

Pages that are already written cannot be overwritten, at least not without a full block erase, so it has to do a remap to append data. Directly logging to an SD card (i.e. lots of small writes) is the fastest way to destroy it.

As I understand it, you need a block erase to change bits from 0 to 1 then you can selectively set bits back from 1 to 0. Couldn't you perform a file append without the need for a block erase? By keeping the unwritten area as all ones until written?

You cannot do single byte writes on NAND. You have erase blocks (typically several 100k to M range) that are divided into pages (typically a few to several dozen k), some devices have sub-pages but that's about it, that's the smallest unit of data you can write.

If you attempt to clear bits from 1 to 0 on an already written page, it will generally not work.

I say generally, because I have actually tried this using raw NAND flash on an embedded Linux device. I found a chip, where it did work, but not very reliably.

I also had an MLC chip, where it did not work, but instead caused random bit-flips on seemingly unrelated pages. I used this trick to systematically hammer down on the pages and figure out the pairings (only document in the NDA version of the datasheet), but failed to reproduce this on a different, more expensive MLC NAND.

But even if appending in this fashion did somehow work, you would still need to update a data structure somewhere else anyway, telling you the exact amount of data written (including cases where you actually append 0xff bytes).

Re: SDcard wear leveling and translation layers (2014)

#19

Post by kragen »

st_goliath wrote: post #18
michaelt wrote: post #17

Earlier quoted context omitted.

As I understand it, you need a block erase to change bits from 0 to 1 then you can selectively set bits back from 1 to 0. Couldn't you perform a file append without the need for a block erase? By keeping the unwritten area as all ones until written?

You cannot do single byte writes on NAND. You have erase blocks (typically several 100k to M range) that are divided into pages (typically a few to several dozen k), some devices have sub-pages but that's about it, that's the smallest unit of data you can write. If you attempt to clear bits from 1 to 0 on an already written page, it will generally not work. I say generally , because I have actually tried this using r…

thank you so much! this is something i've been wondering about for years, and figuring it out obviously took you a huge amount of work

normally with raw nand you use ecc, right? was there any ecc happening in your tests, either on the nand chip or in the linux driver? it seems like if you started with a page with valid ecc data and then tried to bash an arbitrary payload 1 bit in it to 0, you'd have a real challenge updating the ecc data to be consistent with the updated payload

Re: SDcard wear leveling and translation layers (2014)

#20

Post by kragen »

londons_explore wrote: post #12
actionfromafar wrote: post #11

Earlier quoted context omitted.

Is there any Linux compatible file system which will be mounted redundantly without any special mount options? So that for instance a 64 gigabyte would have a filesystem with 32 gigabyte space but with a lot of redundancy? I know there are many ways to achieve similar outcomes but all I know of relies on knowing beforehand how to mount the thing.

Unfortunately because of the way the SD card - computer interface works, storing everything twice on the same card doesn't actually get you much more reliability. The card is unaware of which bits of data are duplicates, and therefore can easily end up storing both copies of some data on areas of the physical flash that are weak - and this is even more likely considering they will probably be written around the same…

i've heard some cards do duplicate data detection? that way they can avoid storing multiple copies of the same data, so for example copying a large file is fast
Post reply on HN