Slavko wrote: > Bob Proulx napísal: > > James Kirk wrote: > > > Since SD is a flash memory and - as far as I know - it has a limited > > > lifetime (in terms of I/O) not thought to run an OS, > > > > The quality of the SD depends upon the vendor. And unfortunately it > > is a "market for lemons" in that it is difficult for consumers to know > > which are better than others. But AFAIK most SD cards do implement at > > least some internal spares and wear leveling. > > I have one RasPi device. I have second SD card Class 10 now. The disk > (SD card) I/O is slow, but with the first card was even slower. The > second one i was selecting by exact type from user's experiences > (measurement) shared on the eLinux.org wiki. The first SD card (slower) > i choose by price... ;-) I wouldn't say the slower device is of lower quality. By quality I was referring to the internal spares and firmware for managing them for wear leveling. A good quality card should last through a lot of write cycles. A poor quality card might die due to being worn out very quickly due to not having good wear leveling. Given two flash storage cards one could be faster but with terrible wear leveling and might wear out sooner than one that was slower but with good wear leveling and lots of internal spares. The class 4 device is slower. The class 10 device is faster. And whether they have good quality firmware and internal spares with good wear leveling is completely unknown from the outside. Writing a full image over a Class 4 8G card: time dd if=image.img of=/dev/sdg bs=64k 121280+0 records in 121280+0 records out 7948206080 bytes (7.9 GB) copied, 1345.1 s, 5.9 MB/s real 22m25.101s user 0m0.068s sys 0m15.213s Writing a full image over a Class 10 8G card: time dd if=image.img of=/dev/sdg bs=64k 121280+0 records in 121280+0 records out 7948206080 bytes (7.9 GB) copied, 625.324 s, 12.7 MB/s real 10m25.331s user 0m0.056s sys 0m16.069s In the above test the class 10 is a little more than twice as fast as the class 4 in this case. It is pretty significant and the price difference very small so I have been buying the faster class 10 cards. So far I have not had any SD cards wear out. And as you might have read in the other message I am using them on very active systems. But I was once fooled into thinking I had a problem due to a bad front panel USB port using a USB-SDHC adapter. The USB port I was using was flakey when used with a particular adapter. Using it I thought an SD card was dying due to various errors. But after some more investigation and more trials with other adapters and ports and other systems and other I realized that it was the USB port I was using. It was my adapter/port combination. The card was okay. It is easy to be fooled by such things. While I haven't worn out an SD card yet I have a handful of worn out USB storage sticks. Of the ones I have it doesn't seem like they have any wear leveling at all and repeated writes to the same FAT32 location can wear out that location pretty quickly. One can be worn out in a month of just blind FAT32 use if it is active enough. > > Talking about tuning the Raspbery Pi folks set vm.swappiness=1 which I > > disagree with. I suggest using the Linux upstream default of > > vm.swappiness=60 or even higher. Proponents of disabling program swap > > by setting it low say that they never want to swap. I have the > > opposite viewpoint. The point is to use the existing ram most > > effectively. If that means using ram for file system buffer cache > > It depends. I have 1 in /proc/sys/vm/swappiness (on RasPi) and for more > month the swap usage is 0. In other words - for my purposes there is a > plenty of RAM. On my home computer i have 10, with no swap usage... It is amazing that a "small" system is 512M of ram. That used to be a "large" system. Everything is relative. A lot of servers on the net are likely still running on much smaller ram images since for many years larger systems were much more expensive to rent. But if you have no memory stress at all then any setting of swappiness would be unnoticeable. Without any resource stress there isn't any difference for any of these settings. It needs to be under resource stress before these tuning parameters have any effect. (Except for fsync() which by design defeats the cache and waits until the disk blocks are written out before continuing.) The Raspbian folks set swappiness in /etc/syctl.conf by the way. In case you decide to make adjustments. Bob
Attachment:
signature.asc
Description: Digital signature