Jump to content


  • Posts

  • Joined

  • Last visited

  1. 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.
  2. 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. 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.
  3. 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.
  4. 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.
  5. 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. 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.
  6. 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)
  7. 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?
  8. 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)
  9. 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
  10. 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? 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. 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 ...
  11. 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 ?
  12. 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 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
  13. 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
  • Create New...