... we're still alive!


I'm actually even more worried about reliability. Last time I heard, as write amplification goes up because there's too little free space (rule of thumb: < 20%-ish free), traditional NAND at its advanced lithography processes of today (< 20nm ?) actually can have realistic reliability problems (significantly low write endurance) (which of course gets even worse if it's MLC or even TLC).
Second that. Actually that's why I signed up right now. Internal irreplaceable storage with a wear like that. To me Flash memory is for desktop use as usefull as LCD screens - both crap, but what we're stuck with today.
IMHO, it must be taken good care to only store on that, what changes on a low frequency, and/or have a multiple of the space you actually need available. I really worry about that.

How do the regular smartphone and tablet OSs handle their internal storage? Do they use it for swap, cache and other temps, logs? (Besides that they're not intended to last that long.)

Would having it worn down in a few years, be acceptable? Will their be a viable repair strategy in place?

Or maybe I'm just paranoid.? o_O
 
I dont understand how paying ~10€ more for 32 isnt a no-brainer.

16GB means you have to dick around with SD-cards. How much time spent researching/buying/waiting/formatting/setting up/failing/installing? You cant even do it once before it becomes unreasonable. Best-case..

And as one of the prime reasons to have spare space. Think about how many returns and frustration can be avoided by just having a recovery-partition?

Just in support-time alone...
 
FWIW, I'd be happy with 4, and ecstatic with 8GB - on my x86 arch linux laptop with XFCE, firefox, claws-mail, pidgeon, gimp installed, my system partitions add up to 3.6GB. I won't be putting any user data on my non-replaceable eMMC (apart from maybe my ssh keys if it's set up like the Pandora). The only thing I really miss with SZ on my Pandora occasionally are the man pages.

Speed might be an issue, but I don't tend to reboot my handhelds very often, and that's the main thing where fast media helps IMO.

Edit: A recovery partition is a reaonable idea, but IMO that shouldn't take more than a couple of gigabytes. You don't want it fully featured, and you probably don't even want any networking running on it, unless you're able to update the libs with remote holes in it - but a recovery partition you reflash every time is liable to be corrupted at the same time as the main partition. On balance, I think a separate computer with updated libs is preferable to a recovery partition most of the time. If my arch laptop needs to have its partitions reformatted, I tend to boot off an external CD drive.
 
Last edited:
add to that an Android chroot somewhere so we can support Android apps using sfdroid (would need a patched kernel with binder, among other things) and 16GB is on the short side. Hence I would like to have 32GB :).

According to kernel devs like gregkh, You can't patch a non-Android kernel for Binder without getting Win9x-level insecurity because it assumes the Android runtime environment will enforce certain security invariants for it.
[doublepost=1459699586,1459699493][/doublepost]
To me Flash memory is for desktop use as usefull as LCD screens - both crap, but what we're stuck with today.

To each his own. I grew up on laptops until 1997 and, when I finally got LCDs on my desktop around 2007, I breathed a massive sigh of relief to finally have crisp text once more.
[doublepost=1459699857][/doublepost]
And as one of the prime reasons to have spare space. Think about how many returns and frustration can be avoided by just having a recovery-partition?

I never trust any recovery media that can be rendered volatile and modified by the software on the main system. If I buy a laptop, the first thing I do is boot off a CD and image the disk, then wipe everything (recovering the space wasted by the recovery partition in the process) and reinstall fresh from a DVD burned from a hash-verified ISO.
 
To each his own. I grew up on laptops until 1997 and, when I finally got LCDs on my desktop around 2007, I breathed a massive sigh of relief to finally have crisp text once more.
True, but think of what it takes to get it to being a viable option for moving pictures. It's just a bad choice to begin with. SED - I think - would have been a good alternative. Anyhow, hopefully it'll get better with Blue Phase Mode LCDs.
 
I have no preference for the eMMC size 8,16, 32GB would all be fine (in fact I have always felt there is a case to make omitting the eMMC <ducks>)...16GB sounds to me like the sweet spot, that will be plenty enough for a quite extensive base system, if you need more then you will probably also run into problems with 32GB or 64GB...
 
quick question:
is the eMMC on the detachable CPU board or on the main board?

in either case i would go for 16GB, but if it's on the main board it would be more important for a larger storage option, to be more future proof.

on my current linux machine, i've got about 14GB for the OS and other software.
 
[...] To me Flash memory is for desktop use as usefull as LCD screens - both crap, but what we're stuck with today.
IMHO, it must be taken good care to only store on that, what changes on a low frequency, and/or have a multiple of the space you actually need available. I really worry about that.
Normally, it's not really a problem. If I remember correctly, even the Intel X25-M from 2008 was rated for 20 GiB of data written per day over 5 years. Recent V-NAND ("3D NAND") is usually VERY durable, but shortly before that became a thing, there has been a phase were durability went down (very very sharply, I think) as density increased.

I once did sort-of a calculation of the Pandora NAND's durability here on the boards, if you're interested.
 
Normally, it's not really a problem. If I remember correctly, even the Intel X25-M from 2008 was rated for 20 GiB of data written per day over 5 years. Recent V-NAND ("3D NAND") is usually VERY durable, but shortly before that became a thing, there has been a phase were durability went down (very very sharply, I think) as density increased.

I once did sort-of a calculation of the Pandora NAND's durability here on the boards, if you're interested.
Hm, when 90% storage are used up by os and app installs, you have only 10% storage left for your calculation. Well, of course the result would tell when those 10% are done, not the whole device.

And then there's that, that actual write amount != intended write amount. With serial writes it won't be far off. But whenever for writing the new data one bit must be reset, the whole containing erase block must be reset. And those resets are the main cause of wear (since they need 10V or so).
On my 256GB ssd the erase block size is 1MB. On those eMMCs I'd gues 128kB? Let's say 1kB, this would still mean a big write amplification, size-wise - and for tiny writes only of course.

Though I have no clue, what the effective average write amplification would be for a normal desktop linux. But some there must be - something between 1.1 and 1.5 maybe.?

P.S.: Was ist Schwuppdizität? :)
 
Granted, I'm not the one who has to come up with the money to fund the upfront change. But, as a user, I would love to see at least 32gb for my device that's going to cost 500€.

Actually this is something that troubles me a bit. Previously there were some small changes, that made the developement slightly more expensive (e.G. change of the Wifi Chip, adding more Keyboard LEDs). Not much, only a few € here and there. But those costs sum up. But still the the estimated prize tag is kept a 500€. So I'm really hoping ED is not sacrificing some amount of his profit margin in order to both keep the prize tag while still improving the specs to fullfill some user expectations.

For me, 32gb is essential also because I want to keep some data on the device itself, maybe some pictures, a movie or two, ROMS, Music and etc so I don't have to worry if I grabbed the right SD card.
I don't see the problem here. If you choose the size of the sd card big enough to hold all your media files, you just can stick to it and would never have to remove it. If even the biggest cards available(x2) are not big enough for you and you would have to grab multiples of them - then even a really huge mmc would be not enough for you.
 
Last edited:
I'd vote for 16GB, I don't think I'd need much more as my data will be on SD anyway.
32GB would be nice but unnecessary I think. I wouldn't put video's, music or pictures on it...
 
Explaining not having everything on the same partition to a regular user, not ideal.

Speed goes up with size. Reads, writes, IOPS etc etc.

Here is an example from odroid.

Samsung Toshiba Sandisk
8G Write 45.4 21.9 N/A
8G Read 113 148 N/A

16G Write 80.1 N/A 25.6
16G Read 126 N/A 153

32G Write 124 N/A 98.7 ← Sweetspot right here. 40MB/s more sequential writes over 16GB.
32G Read 125 N/A 153 ← Dont want to lose over a third to save ~ 10 €.

64G Write 124 83.7 107
64G Read 124 153 153

I understand 10€ extra is 10000€ that has to come from somewhere, but it certainly saves a lot of headache, and it sure adds value.

Looks like the pyra is not for you with all the issues you have with it. Emmc, ram, key layout.
 
doesn't really need to be an actual kernel module does it??

this could be easily made into a C application, making it potentially more accessible....

Not unless you want to run into tons of issues.
Linux recognizes the screen size as 720x1280, when you run the script and enable the SSD with rotation, it turns to 1280x720, however, the framebuffer doesn't really update (thus, our currently used fbturbo doesn't work).

Also, you won't be able to see ANYTHING until everything has been booted, like a bootmenu, etc.

The only proper way is putting this into the kernel, where all other drivers also reside.
 
ok, so a backup is very important. As well as moving, then symlinking whole directory trees to SD just to keep some Nand space...
 
I wonder, do some people forget that there is an internal microSD slot in the Pyra? In the past I have always used a single partition for both / and /home (and now use a swap file rather than a swap partition) as I do not like the idea of introducing inefficiency through such fragmentation, or limiting the size of apt-get install space deliberately; on a Pyra I would likely keep the eMMC, and the OS on it, intact as a backup and use a large microSD card for my normal OS and /home. I expect that the speed difference between eMMC and microSD would be unnoticeable.

For me, the main reason for a larger eMMC (32GiB or 64GiB) is for marketing: to not be seen as inferior by people comparing the specifications of the Pyra and the GPD WIN.
 
Back
Top