On Tue, Jan 07, 2020 at 04:53:13PM -0700, Chris Murphy wrote: > On Tue, Jan 7, 2020 at 4:32 PM Zygo Blaxell > <ce3g8jdj@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > It seems to be normal behavior for USB sticks and SD cards. I've also > > had USB sticks degrade (bit errors) simply from sitting unused on a shelf > > for six months. Some low-end SATA SSDs (like $20/TB drives from Amazon) > > are giant USB sticks with a SATA interface, and will fail the same way. > > > > SD card vendors are starting to notice, and there are now SD card options > > with higher endurance ratings. Still "putting this card in a dashcam > > voids the warranty" in most cases. > > > > ext2 and msdos both make USB sticks last longer, but they have obvious > > other problems. From my fleet of raspberry pis, I find that SD cards > > last longer on btrfs than ext4 with comparable write loads, but they > > are still both lead very short lives, and the biggest life expectancy > > improvement (up to a couple of years) comes from eliminating local > > writes entirely. > > It's long been an accepted fact in professional photography circles > that CF/SD card corruption is due to crappy firmware in cameras. Ergo, > format (FAT32/exFAT) only with that camera's firmware, don't delete > files using the camera's interface, suck off all the files (back them > up too) then format the card in that particular camera, etc. Well, those are all good ideas. One should never assume firmware is bug-free or that any individual storage device is durable or interoperable. I have encountered embedded firmware developers who write their own VFAT implementation from scratch "because [they] don't want to debug someone else's", as if exhaustive bug compatibility was somehow not inherent to correct operation of a VFAT filesystem. > I've wondered for a while now, if all of that was flash manufacturer > buck passing. Consumer SD cards have been ruthlessly optimized for decades, mostly for cost. It will take a while for the consumer-facing part of the industry to dig itself out of that hole. In the meantime, we can expect silent data corruption, bad wear leveling, and power failure corruption to be part of the default feature set. > > > In the most prolific snapshotting case, I had two subvolumes, each > > > with 20 snapshots (at most). I used default ssd mount option for the > > > sdcards, most recently ssd_spread with the usb sticks. And now nossd > > > with the most recent USB stick I just started to use. > > > > The number of snapshots doesn't really matter: you get the up-to-300x > > write multiple from writing to a subvol that has shared metadata pages, > > which happens when you have just one snapshot. It doesn't matter if > > you have 1 snapshot or 10000 (at least, not for _this_ reason). > > Gotcha. So I wonder if the cheap consumer USB/SD card use case, > Raspberry Pi and such, rootfs or general purpose use, should use a > 4KiB node instead of default 16KiB? I read on HN someone using much > much more expensive industrial SD cards and this problem has entirely > vanished for them (Pi use case). I've looked around and they are a lot > smaller and more expensive but for a Pi rootfs it's pretty sane > really, USD$56 for a 4G card that won't die every 6 months? They are > slower too. *shrug* I run btrfs with dup data and dup metadata on the Pis, with minimized write workloads (i.e. I turn off all the local log files, sending the data to other machines or putting it on tmpfs with periodic uploads, and I use compression to reduce write volume). I don't use snapshots on these devices--they do get backups, but they are fine with plain rsync, given the minimized write workloads. I haven't tried changing filesystem parameters like node size. Dup data doesn't help the SD card last any longer, but it does keep the device operating long enough to build and deploy a new SD card. Samsung is making SD cards with 10-year warranties and a 300 TBW rating (equivalent, it is specified in units of "hours of HD video"). They are USD$25 for 128GB, 100MB/s read 90MB/s write. No idea what they're like in the field, I start test deployments next week... > > -- > Chris Murphy >
Attachment:
signature.asc
Description: PGP signature
