Vitel
Active Member
I'm quite happy running Gentoo from SD.
Who's is going run the OS from the SD card?
- Thread starter Austin25
- Start date
MrChops
Member
- Joined
- Sep 2, 2010
- Messages
- 207
I run off sd also, mainly so I can install from the repository without worrying about space limitations and so I have a clean image on my nand in case I want to test a script or something that I'm playing with that I believe would be helpful to the community. However I've noticed that occasionally my pandora will freeze up on start up when booting to my sd card. Specifically it happened a couple of times when my battery went dead. After I plug it in, it would freeze just after the splash screen. Anyone else have that problem? So perhaps thats a small reason not to run off sd, also if your card is slow then you wouldn't want to do it, obviously. I run a class 6 for my boot card and I can't tell a difference in speed except maybe a bit longer to boot up but even that's hardly noticeable or much of a problem since you don't need to reboot much, unless you let your battery die all the time like me 
Tempel
Active Member
Me too! Arch mobile seems to have stalled, but Plugbox seems to be active. Do you know of any others?
Christoph.Krn
Advanced Member
On lifespan of flash-based memory:
What follows is a rough translation of parts of that post. Take it with a grain of salt though, since it includes a good amount of assumptions.
--- BEGIN TRANSLATION ---
Not having found information on this on any of the Pandora wikis, I assume that the flash memory included is SLC ("Sinlge Level Cell" one bit per cell) flash, since UBI is being used to manage the raw flash and at least the creators of UBI have never tested it with MLC flash ("Multi Level Cell", several bits per cell). For SLC flash, you can typically assume that it will withstand 100000 erase cycles, probably many more (if I'm not mistaken, up to several million for NAND with a structure bigger than 25nm). This may not sound like it's all too much, but let's do some math. Assuming one writes 20 GiB of data onto this 512MiB flash memory every day, and assuming a perfect wear leveling, the Pandora's NAND would last for more than 6 years, at least in terms of how many writes (erases) it will withstand. This is when calculating with the assumed worst case of 100000 erase cycles per cell. Of course, there may be other unpredictable reasons why the flash might fail earlier.
So don't worry, the Pandora's NAND will probably last longer than your main system's HDD (unless something unpredictable happens, of course ), and it's likely that other parts of your Pandora will fail earlier.
Please correct me if I've been talking nonsense somewhere.
--- END TRANSLATION ---
------------------------------------------------------------------------
On speed of flash-based memory:
I already wrote about this on the German forums, too: http://forum.gp2x.de/viewtopic.php?p=133184#p133184 What follows is a rough translation of parts of that post.
--- BEGIN TRANSLATION ---
While an SD card's speed class is meant to indicate which minimum transfer speed it can reach, most SD cards more often than not can't hold up to that promise once you do something with them that's a bit more stressful than "just copying over files".
With SD cards, it's the same as it's with SSDs: what's important when running an operating system off of them are IOPS, which is the number of _I_nput and _O_utput operations _P_er _S_econd a storage medium is capable of. Compared to the importance of IOPS performance, the maximum transfer rate is barely of importance when using an SD card for a root file system.
Unfortunately, most SD cards will lose IOPS performance after too much data was being written to them. Even worse yet, many bad SD cards aren't capable of many IOPS in the first place. When using an SD card to run an operating system off of it, using any card capable of handling just few IOPS is deadly for overall system performance. A huge negative impact on performance may occur unexpectedly, to my experience typically after some weeks or months of "normal" usage. These inconsistencies over time and exact usage scenario make it hard to benchmark how well any given SD card is suited for being used for a root file system, as benchmarks may lead to results which don't necessarily represent the overall performance of that SD card very well (if at all). You may remember this kind of problem from some of the earlier SSD benchmarks.
In addition, the SD card market is not exactly transparent. Some SD card "makers" relabel what they can get on the market for cheap, many don't care about consistency of characteristics all too much since they try to keep the prices of their cards down to be more competitive, and thus buy NAND or controllers of varying quality, putting them into the same brand of SD card. Also, there are many well done fakes out there, spoiling the consistency in quality that some of the more expensive SD card brands have (adhere to the Standard Prometheus Response: don't buy SD cards on eBay!). All of this makes it hard to recommend an SD card.
Without having even remotely tested all of the vast number of SD card brands and types you can buy, I'd like to note that to my unrepresentative experience, SanDisk's "Extreme" cards have relatively stable medium IOPS; Panasonic's "Gold" cards are very reliable and durable with relatively stable medium IOPS; Whenever I run any operating system off an SD card, I prefer using one of these two. Still, they are far from the performance you get from SSDs, depending on your usage scenario they may also be a LOT slower overall than a standard grade HDD is. Most of the cheaper cards (like, for instance, Transcend and the cheaper MLC-based SanDisks, to name just two) often get into performance regions in which the user's patience suddenly becomes very important. Again, this is from my experience and not representative, so why hello, grain of salt.
--- END TRANSLATION ---
------------------------------------------------------------------------
On data satefy of flash-based memory:
With SSDs it largely depends on the specific SSD. For instance, Intel's SSDs attempt to fail in a way so that they become read-only but the data remains intact. When they're in that mode, the only way to use up more erase cycles is to trigger an ATA Secure Erase command, which makes them wipe all data stored on them, including the data that's lying around in the so called "spare area", which is an area of the flash reserved for management purposes. Other manufacturers don't care that much about your data and instead more about the speed of their drives so they'll sell better. For instance, even though they're currently pretty popular, OCZ (not SandForce, but specifically OCZ) drives are typically, by both software and hardware design, much more likely to fail in a way which would make your data unaccessible (unless when using very advanced (==expensive) recovery methods) than Intel's SSDs.
Since it's so hard to make a generic statement about reliability of flash-based memory, and because I don't know the exact behavior of UBI and quality of NAND used within the Pandora, I have no idea what you can expect from the Pandora in terms of data safety. I just wanted to explain that unlike for HDDs, you can hardly make any generic statements about data safety of SSD drives.
------------------------------------------------------------------------
Well, I hope at least part of this jabbering, even though quite unstructured and random, was useful for anyone in here.
You might also want to read a recent post I wrote which includes more information about using SD cards as a boot medium: ("File systems", "Reliability/data loss prevention", "Experimental - performance/lifespan increase").
------------------------------------------------------------------------
Version history:
I wrote about this on the German forums: http://forum.gp2x.de/viewtopic.php?p=127213#p127213
What follows is a rough translation of parts of that post. Take it with a grain of salt though, since it includes a good amount of assumptions.
--- BEGIN TRANSLATION ---
Not having found information on this on any of the Pandora wikis, I assume that the flash memory included is SLC ("Sinlge Level Cell" one bit per cell) flash, since UBI is being used to manage the raw flash and at least the creators of UBI have never tested it with MLC flash ("Multi Level Cell", several bits per cell). For SLC flash, you can typically assume that it will withstand 100000 erase cycles, probably many more (if I'm not mistaken, up to several million for NAND with a structure bigger than 25nm). This may not sound like it's all too much, but let's do some math. Assuming one writes 20 GiB of data onto this 512MiB flash memory every day, and assuming a perfect wear leveling, the Pandora's NAND would last for more than 6 years, at least in terms of how many writes (erases) it will withstand. This is when calculating with the assumed worst case of 100000 erase cycles per cell. Of course, there may be other unpredictable reasons why the flash might fail earlier.
So don't worry, the Pandora's NAND will probably last longer than your main system's HDD (unless something unpredictable happens, of course
), and it's likely that other parts of your Pandora will fail earlier.Please correct me if I've been talking nonsense somewhere.
--- END TRANSLATION ---
------------------------------------------------------------------------
On speed of flash-based memory:
Unlike the Pandora's raw NAND, an SSD contains a controller which will handle data management, wear leveling etc. It aren't merely the characteristics of the raw flash which define how well a flash-based memory can handle stress, a huge share of what's responsible for the lifespan and performance of the flash-based storage medium are the management algorithms being used. On the Pandora, UBI and UBIFS are being used to handle data management, wear leveling, bad block management etc. Because most often it's not really possible to compare this to any given SSD controller (or any given SSD controller with any other given SSD controller, for that matter), it's really hard to compare durability and other characteristics of flash-based storage.
Unfortunately, just that it's class 10 doesn't mean that it's good for running an operating system off of it. As I wrote above, it's rather hard to compare the characteristics of various controllers of flash-based memory. This is especially true for SD cards, since as these are mass articles, the quality of different SD cards even from one and the same brand may vary greatly, depending on (among other things) the point in time you buy one and which usage scenario you plan to have it in.Ditto, but Ive just ordered a pair of 32gb class 10, so when those arrive, no excuses for me to try out booting off an SD
I already wrote about this on the German forums, too: http://forum.gp2x.de/viewtopic.php?p=133184#p133184 What follows is a rough translation of parts of that post.
--- BEGIN TRANSLATION ---
While an SD card's speed class is meant to indicate which minimum transfer speed it can reach, most SD cards more often than not can't hold up to that promise once you do something with them that's a bit more stressful than "just copying over files".
With SD cards, it's the same as it's with SSDs: what's important when running an operating system off of them are IOPS, which is the number of _I_nput and _O_utput operations _P_er _S_econd a storage medium is capable of. Compared to the importance of IOPS performance, the maximum transfer rate is barely of importance when using an SD card for a root file system.
Unfortunately, most SD cards will lose IOPS performance after too much data was being written to them. Even worse yet, many bad SD cards aren't capable of many IOPS in the first place. When using an SD card to run an operating system off of it, using any card capable of handling just few IOPS is deadly for overall system performance. A huge negative impact on performance may occur unexpectedly, to my experience typically after some weeks or months of "normal" usage. These inconsistencies over time and exact usage scenario make it hard to benchmark how well any given SD card is suited for being used for a root file system, as benchmarks may lead to results which don't necessarily represent the overall performance of that SD card very well (if at all). You may remember this kind of problem from some of the earlier SSD benchmarks.
In addition, the SD card market is not exactly transparent. Some SD card "makers" relabel what they can get on the market for cheap, many don't care about consistency of characteristics all too much since they try to keep the prices of their cards down to be more competitive, and thus buy NAND or controllers of varying quality, putting them into the same brand of SD card. Also, there are many well done fakes out there, spoiling the consistency in quality that some of the more expensive SD card brands have (adhere to the Standard Prometheus Response: don't buy SD cards on eBay!). All of this makes it hard to recommend an SD card.
Without having even remotely tested all of the vast number of SD card brands and types you can buy, I'd like to note that to my unrepresentative experience, SanDisk's "Extreme" cards have relatively stable medium IOPS; Panasonic's "Gold" cards are very reliable and durable with relatively stable medium IOPS; Whenever I run any operating system off an SD card, I prefer using one of these two. Still, they are far from the performance you get from SSDs, depending on your usage scenario they may also be a LOT slower overall than a standard grade HDD is. Most of the cheaper cards (like, for instance, Transcend and the cheaper MLC-based SanDisks, to name just two) often get into performance regions in which the user's patience suddenly becomes very important. Again, this is from my experience and not representative, so why hello, grain of salt.
--- END TRANSLATION ---
------------------------------------------------------------------------
On data satefy of flash-based memory:
HDDs are likely to take your data with them once they fail, but in some cases at least some of the data can be recovered relatively easy, provided that you know what you are doing and how to do it (which in any case is NO excuse to NOT make good backups!).
With SSDs it largely depends on the specific SSD. For instance, Intel's SSDs attempt to fail in a way so that they become read-only but the data remains intact. When they're in that mode, the only way to use up more erase cycles is to trigger an ATA Secure Erase command, which makes them wipe all data stored on them, including the data that's lying around in the so called "spare area", which is an area of the flash reserved for management purposes. Other manufacturers don't care that much about your data and instead more about the speed of their drives so they'll sell better. For instance, even though they're currently pretty popular, OCZ (not SandForce, but specifically OCZ) drives are typically, by both software and hardware design, much more likely to fail in a way which would make your data unaccessible (unless when using very advanced (==expensive) recovery methods) than Intel's SSDs.
Since it's so hard to make a generic statement about reliability of flash-based memory, and because I don't know the exact behavior of UBI and quality of NAND used within the Pandora, I have no idea what you can expect from the Pandora in terms of data safety. I just wanted to explain that unlike for HDDs, you can hardly make any generic statements about data safety of SSD drives.
------------------------------------------------------------------------
Well, I hope at least part of this jabbering, even though quite unstructured and random, was useful for anyone in here.
You might also want to read a recent post I wrote which includes more information about using SD cards as a boot medium: ("File systems", "Reliability/data loss prevention", "Experimental - performance/lifespan increase").
------------------------------------------------------------------------
Version history:
14jan2011:
15jan2011-1624GMT+1:
17jan2011-2133GMT+1:
18feb2011-0336GMT+1:
- Initial revision.
15jan2011-1624GMT+1:
- Corrected name of SanDisk brand SD card recommendation, now "SanDisk \"Extreme\"" instead of "SanDisk \"Ultra\"".
17jan2011-2133GMT+1:
- Added link to additional information ("File systems", "Reliability/data loss prevention", "Experimental - performance/lifespan increase").
18feb2011-0336GMT+1:
- Minor improvements.
- Corrected changelog consistently saying "2010" instead of "2011" (Duh!). //DOES NOT HAPPEN
Last edited by a moderator:
skeezix
Internal Development
Christoph.Krn -- very nice summary! Can you paste a bunch of that (or links to the posting) to the wikis? Its a nice overall summary of things.
The real question is .. 'given typical class6 or better random SD, will it boot faster or slower than on NAND', and of course the answer is .. hard to say; I've seen faster and slower on different cards of the same label
Theres also the issue of what you're doing during boot (are you splitting things across dual SDs and thus tieing up the controller etc? but thats a little esoteric.)
I'll have to nab a big fat card myself .. I tend to use dual-8s, since they're cheap and 16GB is pretty hefty; but once you start piling stuff on, it does go quick.
jeff
The real question is .. 'given typical class6 or better random SD, will it boot faster or slower than on NAND', and of course the answer is .. hard to say; I've seen faster and slower on different cards of the same label
Theres also the issue of what you're doing during boot (are you splitting things across dual SDs and thus tieing up the controller etc? but thats a little esoteric.)
I'll have to nab a big fat card myself .. I tend to use dual-8s, since they're cheap and 16GB is pretty hefty; but once you start piling stuff on, it does go quick.
jeff
I have a PNY Optima 16GB card in my Wiz right now, it does fine for eiher single large files or small files. As long as you are working with a single file (or just an emulator and one large ROM or ISO file) it works great. However, copying or accessing large numbers of files (either during a copy operation from desktop to card, or an app scanning directories on the card) takes a rather long time.
Christoph.Krn
Advanced Member
Since I plan to /truly/ dig into everything Pandora when I get mine, I have not really looked through the wikis thoroughly yet. Thus, I don't really know what the best place(s) would be to put this into.
Since I have already written many more texts like this one which are scattered throughout the German forums, my plan is to put the important bits wherever they belong once I got my Pandora, in the process eliminating the loss of structure induced by translation and consolidation. This goes along with an older plan of creating a central Pandora information index (as a starting point for completely new users), which is meant to vaporize the problem that currently it's often hard for new users to find specific information (since we have multiple wikis and forums with many lists, FAQs and information of varying importance wildly mixed up). Because I believe this might be misinterpreted by some people, let me note that I can't say for sure that I'll actually do this. I can't know how much time I will have for this after I received my Pandora. Also, since I began planning this about a year ago, I'm very sure it would need more than one maintainer (at least when implemented the way I imagine it).
Last but not least, personally I don't really see the quality of that post /in its current incarnation/ as being high enough to be included in documentation, for it's unstructured and at the same time not comprehensive. But that's what you get when combining simple translations, which sometimes is still better than nothing at all. Anyway (and to finally end this weird explanation), since it should always be up to others to judge about anything someone does, anyone may of course link to that posting from wherever she sees fit. I might update that post, so think twice before copying parts of it somewhere else / quoting it. You also have permisson to copy ((edited/altered) parts/versions of) it into the wikis without the need of giving me credit.
Some people have reported that it's especially so if you don't have a Pandora.
Also, good to hear that a "typical class6" card is at least not much worse than Pandora's NAND, which means there might be room for optimization with good cards.
gruso
thunderbox
I'm running from NAND for everyday use, but I do have a boot SD set up for developing (not that I'm a dev, let's call it typing make) and opkg mischief. I learned the hard way that doing this stuff on the NAND has certain risks, like filling up the NAND and having to reflash - losing all your work.
My boot SD came in very handy today. I was fiddling with xorg.conf (don't do that) experimenting with colour modes. Getting this wrong means no window manager, not even a login screen. No dramas - boot from SD, mount the NAND, undo changes to xorg.conf, reboot from NAND.
My boot SD came in very handy today. I was fiddling with xorg.conf (don't do that) experimenting with colour modes. Getting this wrong means no window manager, not even a login screen. No dramas - boot from SD, mount the NAND, undo changes to xorg.conf, reboot from NAND.
Dude
Still Fresh
I will be trying to run different OS's occasionally, and have been looking at performance benchmarks.
Christoph is right on with the I/O bench. Some of these sd really are showing extreme differences.
Thanks for the info.
This is one of the benchmarks I found on the web...SDHC Benchmark
Christoph is right on with the I/O bench. Some of these sd really are showing extreme differences.
Thanks for the info.
This is one of the benchmarks I found on the web...SDHC Benchmark
kaprikawn
Very Active Member
That benchmark is why I've got myself a couple of the Samsung SD cards. The other two above are a bit too expensive. The Samsung is the best IO performer at a reasonable price (according to that benchmark).
Anihil8ion2199
Member
- Joined
- Nov 4, 2010
- Messages
- 369
Really great info Christoph.Krn. Thanks for those informative posts!
tsh
Active Member
The good thing about the wiki is that you can put your text into any 'reasonable' place and reasonably expect someone more familiar with the structure to move it for you. Also applies to proof reading, etc.
I would today make Storage_performance a topic in its own right, covering lifetime and throughput. It can then be linked from any page which discusses NAND or SD.
Christoph.Krn
Advanced Member
I updated that long post above because I made a mistake. Here's an excerpt of the version history:
Here's an SD card comparison chart by the German website "chip" (German language link) (automatically translated to English via google translate). Chip is not usually high quality though (for instance, the current issue of their print magazine says "7 shocking truths about Windows" on its front page and they are very sensationalistic), so be careful with that chart. Comparing the data given in the chart with what I've experienced with some of the brands listed there, it seems to be rather accurate though (remember that currently it's nearly impossible to create reliable and representative benchmark results).
------------------------------------------------------------------------
But as I said, anyone may copy ((edited/altered) parts/versions of) that post into the wikis without the need of giving me credit.
------------------------------------------------------------------------
Thank you, this might come in handy.
Here's an SD card comparison chart by the German website "chip" (German language link) (automatically translated to English via google translate). Chip is not usually high quality though (for instance, the current issue of their print magazine says "7 shocking truths about Windows" on its front page and they are very sensationalistic), so be careful with that chart. Comparing the data given in the chart with what I've experienced with some of the brands listed there, it seems to be rather accurate though (remember that currently it's nearly impossible to create reliable and representative benchmark results).
------------------------------------------------------------------------
Yes, thank you, I was aware of that. Because I planned to structure this information after I have my Pandora, and since the Pandora always seems to be just TWO MONTHS™ away, it always seemed like it's worth waiting in order to be able to put the information together (as opposed to publishing it unstructured). Unfortunately, it already took a plethora of TWO MONTHS™ for my Pandora to become reality, so I probably should have put the unstructured information into the wikis, but I had no idea that would happen.
But as I said, anyone may copy ((edited/altered) parts/versions of) that post into the wikis without the need of giving me credit.
Last edited by a moderator:
tsh
Active Member
Anyone who does boot from SD might want to think about doing backups of their SD regularly - mine has just failed to copy with dd at 5.7/16GB. I'd hate to have to work out what I have already opkg-installed on it and go through that again!
urjaman
"I Know. We're going for a ride."
tsh
Active Member
I think it was nothing critical, e2fsck seems to have fixed it (or it thinks it has). So much for cheap SD cards!
Christoph.Krn
Advanced Member
I updated that long post above with a link to additional information ( ("File systems", "Reliability/data loss prevention", "Experimental - performance/lifespan increase") ). Here's an excerpt of the version history:
Anyone interested in running an operating system off an SD card might be interested in that information, so I thought it might be a good idea to put an update notification (this post) into this topic.
Anyone interested in running an operating system off an SD card might be interested in that information, so I thought it might be a good idea to put an update notification (this post) into this topic.
Last edited by a moderator:
