3 ms·

Out of interest, how did you approach disk encryption? That would be my concern with removable storage. The other thing I'm keeping an eye on is Arm's LittleFS

by skl_ 8y ago

Out of interest, how did you approach disk encryption? That would be my concern with removable storage. The other thing I'm keeping an eye on is Arm's LittleFS for storage longevity.

dividuum 8y ago
It's possible to write 256 bit of user data to the Pis internal OTP memory. You can store a non-changeable key there. Of course that's then easily readable if you can run execute commands on the Pi. LittleFS (recently posted here) is indeed interesting, although from the documentation I couldn't figure out 1) if it works for larger devices as it seems it seems mostly intended for sizes of a few MB. I might be totally wrong with that. 2) if/how it handles corruption of complete blocks(?) of SD memory. As far as I understand, an SD card doesn't necessarily use 4K block sizes and corruption might hit multiple blocks at once. If LittleFS stores both previous and next version next to each other, I don't think that'll help in that case.
- skl_ 8y ago
  Oh, there's an OTP in the MPU? I didn't know that. Yes with 1) I'm not sure either but there's some sporadic discussion in the Github issues with various attempts. From what I remember certain scenarios currently cause all blocks to be re-scanned which will obviously get slower with capacity. With regards 2), I was under the impression each block is allocated according to the wear-levelling algo[0] so I don't think they're contiguous if that's what you mean. Also block size is configurable. I tried implementing LittleFS on a 32MB SFDP flash with Mbed but couldn't get any decent performance out of it. It kept spewing out "bad block" errors an re-allocating everything. I hope it's a more viable option in future though as I do like the design. [0] https://github.com/ARMmbed/littlefs/blob/master/DESIGN.md https://github.com/ARMmbed/littlefs/blob/master/DESIGN.md
- opless 8y ago
  I posted it (though I'll freely admit hackaday was the source that I discovered it through) Personally I want to use it as an internal filesystem for various projects (like games - instead of zip/pak files, which are really read only) even littlefs over https might be an interesting naval gazing project :D
Abishek_Muthian 8y ago
I store the data in encrypted USB flash drives & store the key in eCryptfs on the SD card.

by skl_ 8y ago

Out of interest, how did you approach disk encryption? That would be my concern with removable storage. The other thing I'm keeping an eye on is Arm's LittleFS for storage longevity.

dividuum 8y ago

It's possible to write 256 bit of user data to the Pis internal OTP memory. You can store a non-changeable key there. Of course that's then easily readable if you can run execute commands on the Pi. LittleFS (recently posted here) is indeed interesting, although from the documentation I couldn't figure out 1) if it works for larger devices as it seems it seems mostly intended for sizes of a few MB. I might be totally wrong with that. 2) if/how it handles corruption of complete blocks(?) of SD memory. As far as I understand, an SD card doesn't necessarily use 4K block sizes and corruption might hit multiple blocks at once. If LittleFS stores both previous and next version next to each other, I don't think that'll help in that case.

skl_ 8y ago
Oh, there's an OTP in the MPU? I didn't know that. Yes with 1) I'm not sure either but there's some sporadic discussion in the Github issues with various attempts. From what I remember certain scenarios currently cause all blocks to be re-scanned which will obviously get slower with capacity. With regards 2), I was under the impression each block is allocated according to the wear-levelling algo[0] so I don't think they're contiguous if that's what you mean. Also block size is configurable. I tried implementing LittleFS on a 32MB SFDP flash with Mbed but couldn't get any decent performance out of it. It kept spewing out "bad block" errors an re-allocating everything. I hope it's a more viable option in future though as I do like the design. [0] https://github.com/ARMmbed/littlefs/blob/master/DESIGN.md https://github.com/ARMmbed/littlefs/blob/master/DESIGN.md
opless 8y ago
I posted it (though I'll freely admit hackaday was the source that I discovered it through) Personally I want to use it as an internal filesystem for various projects (like games - instead of zip/pak files, which are really read only) even littlefs over https might be an interesting naval gazing project :D

Abishek_Muthian 8y ago

I store the data in encrypted USB flash drives & store the key in eCryptfs on the SD card.