[Boot from eMMC with blank SD in slot (BPI-M3)]

And we can still boot from a inserted SD card, if there is somethings wrong with the eMMC? So the "original boot loader" isn't changed and the SDCard is prefered before the eMMC?

Thanks.

[SD card performance]

I think it is because to move data you first write it in RAM and Linux uses all the

available RAM for it.

 

My first thinking too, but f3 doesn't use cache (under linux - see homepage of f3) but writes directly. Verified by the values of the top program.

 

 

24MB/s is not that much or in other words: An indication that F3 uses rather small block sizes. Please compare with post #45 and #48 here: http://forum.armbian.com/index.php/topic/990-testers-wanted-sd-card-performance/?p=9886

 

Would be interesting if it's a thermal issue or not (I had the same issues on Beelink X2's eMMC way early)

 

Checked with another board, same behavior. But now I monitored it with armbianmonitor running by side. Temperature starts at 50°C, with the high IO values. After 2GB of writing the temperature reaches 72°C and the rate drops to 7MB/s. Both stays there to the end of writing. Board was without any cooling at all.

 

Checked now with my new heat sink (passive one, covered the CPU full, but the 4 eMMC only partial). The writing rate is now nearly constant 11 MB/s. The temperature starts at ca. 40°C (hehe, its really hot here in Germany at the moment ) and goes to approx. 52°C. And this only with a f.. simple heat sink. Why they don't deliver one mounted as standard. These are only cents. And we have with armbian already a cool system, not comparable with the original android they deliver. So I love my Odroid C2, already a nice heat sink mounted and it stays cool.

 

So why the check with f3 and not iozone?

1. I want to verify the eMMC. And both boards are ok.

2. I want to check if there are IO drops, if the used memory get higher. Think of some Samsung SSDs, they have lousy rates if they are nearly full, or think of NVidias disaster with some 4GB Video cards, with the slow last GB.

 

So maybe a interesting comparison, check the io rate with iozone on an empty card. Create a huge dummy file and compare it again with iozone. Btw, don't know how much space is required for iozone.

[SD card performance]

Some quick test with f3write on eMMC on Orange Pi+ 2E. Writing speed starts with excellent 24MB/s. After approx. 3GB written data the writing rate drops nearly instantly to 7,5 MB/s and stays for it until the end of the 12GB.

Any clue why this happens? Reading rate is about 60MB/s, not so bad.

[nand-sata-install script]

After moving the system from uSD to emmc on OPi+2E and rebooting, I don't have any access to the uSD card anymore. "fdisk -l" and "blkid -c /dev/null" doesn't show anything. Nothing in journal and syslog.

Reinserting and reformation (on other PC) doesn't help.

Any clues?

 

Thanks.

[Unix tools to write images to SD cards]

Since this thread here is about writing OS images to SD card recommending ddrescue is a really bad idea

 

Sorry, you misread me and so I disagree here. You are right, for writing back the image from a "defect" SD card this tool is nearly perfect (that's why I hinted it).

 

And for the mentioned topic: For writing the image to the SD card, you can use this tool too, but this doesn't mean, you can use bad SD cards as target, because ddrescue is trying to rescue the good parts first in case of read errors, not write errors! So it doesn't allow you to write to a broken SD card, it simple stops with error message. So no difference to dd (besides progress bar and statics) and dc3dd.

 

 

I started preferring this GUI method after I f*cked up a HDD by making a typo in a DD command (accidentally writing the SD-card image to a HDD).

 

S.. happens , my sorry to you. So you can use the Suse Studio Imagewriter (available on most distros, not only on OpenSuse, no KDE or GNOME needed, runs "standalone" everywhere), exactly what you need, writes images only to USB drives, so no fear to destroy your harddrive.

 

PS: Because most images are compressed (gzip, tar etc.), I prefer the CLI on-the-fly command as already written down.

[Claim a task, set DUE date and start doing it!]

Some additional minds, handling the log into ram. Doing this with an onion fs on /var/log (that's why I asked, if the different kernels do it support - my fault, I wrote raspian kernel, but meant armbian ), could reduce the first "rsync time" and may be other trouble with already opened files.

 

Remark: with my odroid c2 and omv the dir /var/log is handled by folder2ram and logging does work fine. Couldn't test it with rambian now, because it's my working server (and my first and only once arm board at the moment)

[Claim a task, set DUE date and start doing it!]

This task is not that simple, logging starts at early boot, so you need to mount /var/log and restore its contents as early as possible, before rsyslog/journald starts. I already linked one of possible solutions here, but it needs to be packaged with proper pre- and postinstall scripts to make it optional.

 

Sorry, but I don't see the principal difference between ramlog (with or without systemd) and folder2ram, beside that ramlog only handles /var/log and folder2ram would handle all self defined folders, including /var/log. See https://github.com/bobafetthotmail/folder2ram.

Or did you mean with not simple to package it with all usage cases (w/o systemd) in armbian?

[Unix tools to write images to SD cards]

I prefere ddrescue, because "It uses a similar technique as dd and copies block by block, but has an intelligent algorithm to recover failed data." (see Gentoo wiki). Not a bad idea, if we use SD cards as the boot/root medium.

 

And of course, some write progress and statistics

 

And if you have the zsh installed, you can even write the compressed image on the fly to the SD card (maybe it does work with bash too):

ddrescue --force =(unzip -p  /imagepath/image.img.zip) /dev/mmcblk0 (for internal card readers or use the common /dev/sdx device)

[Claim a task, set DUE date and start doing it!]

We were using a simple tool called ramlog to store logs in ram and sync them with cron & shutdown. https://github.com/igorpecovnik/lib/blob/master/bin/ramlog_2.0.0_all.deb 

 

Since it's not systemd friendly, we don't use it on modern installs. Something similar to this would be nice to have. 

 

 

For this simple task package folder2ram fits perfect and would be enough. Could be "borrowed" from the OMV repos

Imho, this tool could be improved, for usage cases like:

• sync periodically, not only on shutdown (thinking of the mysql database)
• don't sync at all back to the (sd-card-)folder, throw away all changes (e.g. for /var/log, and no, putting /var/log as tmpfs in fstab isn't enough, because some services needs /var/log/servicename/logfile, which isn't available than)
• use a overlay fs, could be a improved start up time for large sync folders. But I don't know, if all raspian kernels have it implemented. And I haven't any clue, what the overall performance would be.

The last one is the approach of anything-sync-damon (systemd ready), already mentioned by zador.blood.stained.

 

Regards sysitos

[Claim a task, set DUE date and start doing it!]

 

has very limited use cases, on servers you usually want to control what you want to mount

 

And that's the script for. You can control it, no interaction required. You have a black/white-list for defining, if it should be mounted, if and how it should be shared.

He, these little arm boards do only need very little power. That's why, I let it running the whole day ( in opposite to my real AMD Server).  But if there are multiple USB drives connected, the power consumption goes high too. So I switch these drives only on, if I need it. Think of it as "poor man's USB NAS".  Or people like my mother without a smart TV. She only needs to plugin the USB drive and can watch the pictures/movies with Kodi on TV.

 

Btw. would be nice if the power source -220V- could be switched with the pins of the board too. Suggestions?

 

 

some people might not like systemd

 

Yes, i know these flame wars . On my little nexx router with openwrt I used a "simple udev script". Was working too. But now with systemd it's more comfortable and more powerful.

 

 

There shouldn't be any issues installing this or this manually

 

 

Thanks, for the suggestions, already had a look on it. With OMV on my Odroid C2 there is the package folder2ram (prefer existing packages), but this does only sync on startup/shutdown, which is sometimes not enough ...

[Claim a task, set DUE date and start doing it!]

As I already wrote in my first post, I see the Orange Pi+ 2E as one of the best mini servers. So could someone with an Orange Pi+ 2E and a fresh raspian please monitor the write rates of the eMMc (e.g. with: awk '{print $7}' /sys/block/mmcblk0/stat ) over some time? Maybe with a running mysql server database on eMMC?

 

Asking, because I haven't seen a package like folder2ram or similar to prevent the "fast flash memory dead" on raspian. Or is there a need for it?

 

Regards sysitos

 

PS: Because I'm new to this forum (until now I was only passive reader, thanks to the interesting posts of tkaiser on the web), and I got only 1 response to my automount&share script, could someone of the advanced members help me to interpret this? Does this mean, there is no interest for it, because all here know how to write scripts and the noobs, who are interested in, are don't post here?  Or is no response simple the most of all responses ?

[HOWTO : NFS Server and Client Configuration]

Hi Gravelrash,

 

I prefer a defined place for server shares. So I have already done within my automount&share script.

So imho a good place would be /srv/nfs for nfs shares (/srv/smb for samba etc.)

 

Disadvantages: You need an additional mount within this directory, but this is quick done by: mount --bind or mount --rbind

 

Advanatges: You are more flexible and see what you have shared, permissions could be set too. Additional mounts could on the fly be shared by binding they in the parent share (valid at least for NFSv4 and samba).

 

As I already mentioned, this is how my automount&share script is working, but I think, you was the only one who was interested in

 

To you exports file

 

the following will allow both v3 and v4 clients to access the same files

# Export media to allow access for v4 clients ONLY
/media/Disk1 *(rw,async,insecure,no_root_squash,no_subtree_check,fsid=0,nohide)

# Export media to allow access for v3 clients
/media/Disk1/Data *(rw,sync,insecure,no_root_squash,no_subtree_check,nohide)

 

It is correct, for NFSv4 you need a root directory, defined by fsid=0. And there could be only one. So if you have Disk2, it can't be shared additional in this way. Or you mount Disk2 within Disk1, not the best idea That's why, my suggested solution is the better one.

And NFSv3 clients could access the NFSv4 server share too, no need to share it twice.

 

Remark: Some old NFSv3 clients have problems with NFS shares and file system boundaries (e.g. the mentioned Disk2 mounting within the mounted Disk1). These problems could sometimes be resolved by giving the correct share options (nohide etc.) and an unique fsid and a separate sharing entry in the exports file. Also be done (beside the fsid, but there is something within my mind) with my script   

 

But never-less, for some clients I would prefer a different sharing solution, if the shares are changing often. So I use samba with my mini server and kodi and GBit Lan.

 

By the way, you could write down some advantages for NFS (lower overhead and so more speed on slower networks, better ACL handling, better usable on linux clients, easier sharing if you have permanent ip addresses).

 

Regards sysitos

[Claim a task, set DUE date and start doing it!]

Hi,

 

I also want to claim a task.

Imho, from all the available arm boards the Orange Pi+ 2E could be one of the best mini servers.

 

That's why, I would provide a usb automount/autoshare udev/systemd script for it to simplify some server tasks. In the meaning of simple plugin USB drives and forget about it.

(I know, there are already some automount tools, but none of them meet my needs.)

 

So what exactly does it do:

for plug in:

•  mounts USB drives with their label under specified mount point, ignore drives on black list and fstab, mount drives with uuid if label is already mounted
• optional: share the new mounted drive with samba and nfs (create a special exports file), other servers as ftp are possible too

for unplug

• unshare and unmount the drive, clean up the changed files

 

To be fair, all this is already done and is running here fine with OMV and my ODROID C2. (OMV was the first working image for the C2).

I have only tested the new C2 armbian image.

 

So what must be done until this goes public on armbian?

1. clean up the code

2. create a deb package

 

optional

3. use external default/custom ini files (better than changing the whole script)

4. extend the script for other servers and other purposes

 

Ok, and some docu could be helpfull

 

Maybe it's useful.

Any thoughs?

 

PS: script is working only with systemd

 

cu sysitos