trohn_javolta wrote:@meveric If you read the explanation from tkaiser here:
https://forum.armbian.com/index.php?/to ... entry42819
concerning running os from hdd you may reconsider your previous statement about read/write speeds...at least if you're running armbian with all its tweaks.
First of all I'm not using armbian, therefore I don't really care about these "optimizations" in fact I'm pretty much against these optimizations from a sysadmin perspective.
For some people pushing everything in RAM seems to be the holy grail. For me it's the worst thing you can do.
If your system crashes and your logs are in RAM your logs are lost, after reboot they are gone and you can't even check why the system crashed or what was happed right before the crash.
Maybe the out-of-memory killer killed an important task, cause you had to much stuff in RAM? You'll never know, cause the log is gone when the board crashes.
But they probably tell you they have the 10min sync active, so at least you know what happened 10min before the crash
Browser Cache in RAM, another stupid idea in my opinion.. the only accelerated browser on ODROIDs is Chromium, which is known for using huge amounts of RAM to operate, and you want to put even more useless data like all the pictures, flash animations, gifs, youtube videos and so on in RAM as well? Sounds pretty stupid to me
If you happen to browse one site at a time and never open more tabs, this might work for you, but just so you get an idea of my browsing behavior: at work I have 5 Firefox windows open, with a total of about 500 tabs
on my home PC that's even more.
Also I'm using my boards for gaming, file storage and compiling games and programs for ODROIDs.
If I play games on my system, I don't want to fill my RAM with useless data like logs, or browser cache or other stuff, some of the games I play use 1.3 GB RAM or more and use quite a bit of texture memory for GPU as well, so I don't want to fill my RAM with background stuff, that can run on HDD as much as it wants as long as it doesn't bother me.
I don't care if a game takes 10 seconds to load or 15 seconds. Once data is in RAM it's in the RAM and I don't care about loading times anymore as the level I'm currently playing is in already loaded.
In fact some emulators even allow to load the entire image into the RAM (Playstation 1 emulator and some other) which can be quite handy at times IF you have the RAM.
File-Server for movies, games, etc:
Large sequential data; Means I don't care about random read or write performance, but if I rip a blue-ray disc with about 40GB and copy that from one partition to another, or use handbreak to convert it, I rather have constant 100 MB/sec write performance than eMMC with is much slower.
And once again: as soon as the OS is loaded it's running in memory all your Kernel and drivers sit in the memory if you want to support this you can even activate a cache program such as preload which will load and keep the drivers that you use the most constantly in ram/cache, what do you need random read/write for an OS that's just idle in the background anyway?
If the OS runs, it runs and doesn't constantly load something. It occasionally will write some logs and that's fine with me, nothing that would stress a HDD.
High random read helps to reduce the boot-time of the OS, or if you have a server with tons of tiny files (e.g. WebServer with several thousands .js or .css files) that need to be constantly loaded and are not cached.
If you DO NOT have any services running that need constant read or write of tiny chunks of data on your rootfs, what's the point of having fast random read/write for an OS that just sits and idles 99.9% of the time?
Compiling programs:
I compile tons of programs and games, and one of the most limiting factor in my work is lack of RAM. Compiling Chromium Browser for example can easily take 3-7 GB RAM only running on two threads (I don't even dare to use more than the minimum). As you know the ODROID only has 2GB RAM, and even with ZRAM you can't fit the entire code in RAM alone and SWAP on HDD is used as well, slowing down the process even more.
Putting logs, caches and whatever armbian does in the RAM for "optimization" would slow down me even more, much more, in worst case to a level where I can't even work anymore, cause there's too little RAM to begin with at all.
Or here's a nice example of
Link Time Optimization for mame2014 if you have a hard time counting, that's about 5.5 GB of RAM that's used.
So believe me, putting more and more stuff in RAM is like the worst thing you can do in that case (although I understand not everyone does the same stuff I do).
It's true, that compiling would actually benefit from eMMC storage, as in that case random read/write are actually used quite often, but sadly the amount of data I'm currently using for all the software projects I have, is about 1TB, and even spread over several ODROIDs, that doesn't fit on any eMMC anymore
Other issues:
Programs happen to run in a "unlucky" state, I know this from work, as I work for a software development company and our developers don't care much about logging, and it happens quite often, that programs run in a state where they log the same error code over and over again, sometimes as fast as the OS can write; filling our HDDs in no time with logs. Now imagine this is in a setup with logs only in memory.
Either you completely fill your RAM in a short amount of time until the system can't work anymore, or if you were intelligent enough to limit the size of your log folder in memory, the system will stop logging, causing some programs to stop working or crashing. Both is not desirable
More infos about my setup:
My main ODROID (an XU3 running GameStationTurbo) which I use for all my tests of games, programs, and so on currently has a 200GB rootfs partition (too big for any eMMC), and NO, that does not include ROMS, these are actually mounted via network and is a partition of it's own on another ODROID and currently use about another 150GB in size.
here are some iozone infos about the HDD:
Code: Select all
Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
random random bkwd record stride
kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
102400 4 10897 12938 13133 13332 506 1549
102400 16 31101 36834 39311 40168 2080 6167
102400 512 73443 83823 85266 82032 37572 57522
102400 1024 81670 85593 94826 98024 53907 75954
102400 16384 92388 99181 96908 96845 92905 98119
sadly the random read suffered a lot, due to a lot of abuse of the HDD, so tiny files (4k and 16k) are extremely slow, starting at 512K it's quite fast though.
For comparison on the same system my 64 GB eMMC that's still connected to the system:
Code: Select all
Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 -f /media/odroid/GameStationTurbo/test.file
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
random random bkwd record stride
kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
102400 4 4057 4056 9596 9401 9880 3149
102400 16 6839 6770 26421 26731 28056 6567
102400 512 48132 52348 116821 119011 113687 48458
102400 1024 51499 56040 141933 140928 137685 52174
102400 16384 58974 60150 179162 190544 193768 59275
The eMMC test shows also nicely that larger eMMC are faster than the smaller ones. a "new" 16GB eMMC as seen on the link you gave above maxes at 145 MB/sec, this "older" 64GB eMMC maxes at 193 MB/sec.
Aside from that, if you compare the values you can see at 4 and 16K the eMMC is indeed faster, although ONLY in random read and write.
After that, the HDD wins in random write (yep HDD is faster in random writing than eMMC), while the eMMC still beats it in random read (which is expected).
You might wonder why it looks so different compared to the tests on the site of armbian, where the 16GB eMMC seems to be faster.
eMMC do have a higher wear level than HDD do, and my eMMC is about 1-2 years old, and for that suffered some wearing. It would be even worse if I had not done some fstrim first on eMMC, which improves performance quite a bit.
Without regular fstrim your eMMC performance will drop to about original 50% speed rather quickly.
But they don't tell you that on their tests either
eMMC excels in random read, aside from that a regular HDD will probably always beat a eMMC.
So yes, for fastest boot up time, and to access tons of tiny files like for webserver, or maybe for database server, eMMC might be much better than a HDD, for other purposes, not so much.
And here's another crazy idea... Since you already have a Cloudshell 2 and can connect 2 HDDs anyway, how about using a SSD for the OS and a large HDD for lots of data, that way you outperform the eMMC is all fields
