Jump to content

sysitos

Members
  • Posts

    13
  • Joined

  • Last visited

Reputation Activity

  1. Like
    sysitos reacted to miked in Claim a task, set DUE date and start doing it!   
    Sorry if getting off topic, but... a relay does that. Search "arduino relay" on ebay (< $2) or amazon etc for the easiest solution. Cut the live wire of a power cord and put the relay module in between.
  2. Like
    sysitos got a reaction from Gravelrash in 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
     
    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
  3. Like
    sysitos reacted to tkaiser in SD card performance   
    Warning: This whole thread is only about historical information now since it's 2018 and we can buy inexpensive and great performing A1 rated SD cards in the meantime. Buying anything else is a mistake so directly jump to the end of the thread for performance numbers and recommendations.
     
     
     
    Edit: See an early 2017 update at the end of the thread regarding new SD specs also covering random IO performance.
     
    Edit 2: Some thoughts/observations on lifespan/reliability of SBC storage: http://tech.scargill.net/a-question-of-lifespan/ (see also/especially the comments there)
     
    Edit 3: CNX Software picked up recent performance reports (eg. by Andreas Spiess) and other important issues around SD cards: http://www.cnx-software.com/2017/06/13/micro-sd-cards-for-development-boards-classes-tools-benchmarks-reliability-and-tips-tricks/
     
    Edit 4: See an early 2018 update testing real world A1 performance class products at the end of the thread.
     
    Edit 5: See here and there for some rather boring but very important information about Armbian's tries to prevent SD cards wearing out too fast.
     
     

     
    Preparations:
     
    I tested 8 different SD/TF cards under identical conditions. I created an Armbian 5.07 image to be used on Banana Pi (A20 SoC with 4.4.6 kernel, ext4 rootfs (Armbian defaults == no journal), 960MHz scaling_max_cpufreq, scaling_governor == performance. All test runs were done using 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' and monitored using 'sudo iostat 5' for anomalies (none detected).
      Kernel version matters (since with Allwinner's 3.4 kernel sequential throughput is limited to ~16MB/s, with mainline kernel we get close to Banana Pi SDIO implementation's max: ~23MB/s) and filesystem settings matter too (enabled journal for example slows down 4K writes a lot).   Sequential speeds:     Random I/O:     The 4 Samsung cards were bought within the last 3 weeks and manufactured between 09/2015 and 12/2015 according to the card's metadata. Interesting observation: I used three of these cards the first time and they all show identical behaviour especially regarding writes with small record sizes: pretty slow in the beginning and getting faster over time (the Samsung Pro for example started with only 1400KB/s 4K writes and 3 runs later the same test showed 3270KB/s -- maybe an indication that some sort of calibration happened. Anyway: I know why I always repeat tests and do not rely on a single test run)   Sequential speed mostly irrelevant / random I/O differs and matters a lot!   The SanDisk Extreme Pro has been bought nearly 3 years ago. This card shows superior sequential read/write performance compared to the three Samsung EVOs. But only when used in combination with a host that can make use of these speeds. My MacBook writes 4 times faster an OS image to the Extreme Pro compared to the EVOs. But this doesn't matter at all since the SDIO implementation of the board in question is limited to ~23MB/s (50MHz @ 4 bit). The same sequential write/read speed limitation applies to most SBCs since to be able to exceed this slow mode the voltage the SD/TF card is fed with would've to be adjusted (default 3.3V, the faster modes require a dynamic switch to 1.8V instead which some/most SoCs can perform but if the SBC vendor doesn't implement this you're limited to ~23MB/s).   Therefore cards labeled as being capable of "up to 90MB/s" do not perform different than those that can only do "up to 20MB/s" as long as we're talking about sequential transfers since the SD card interface is already the bottleneck. But since we're using SD/TF cards not in cameras but as storage media for the rootfs of an SBC something different is more important: Random I/O. And here performance of cards that are labeled identical ('class 10' for example) differs a lot.   All 4 Samsungs outperform the other cards easily in this area. The SanDisk Extreme Pro can not compete regarding random I/O compared to superiour (but mostly irrelevant) sequential transfer speeds. And funnily the 3 other cards show horribly slow random write performance, especially with 16k record size. According to card metadata the 2 Intenso are oemid 0x5048 / manfid: 0x000027 (cheap crap known to die way too early) and I would believe the SanDisk 'class 10' card is a fake or at least uses the same controller as the 2 Intenso since 16K random writes are also way slower than 4K writes.   Detailed results (summary table also available as .ods, .xlsx or .txt):   Samsung Pro 64GB (brand new) http://sprunge.us/DEYd   Samsung EVO+ 64GB (brand new) http://sprunge.us/NLQd   Samsung EVO+ 32GB (brand new) http://sprunge.us/heGL   Samsung EVO 64GB (already used some time) http://sprunge.us/DUOS   SanDisk Extreme Pro 8GB (already used some time) http://sprunge.us/ZPFZ   SanDisk 'Class 10' 8GB (already used some time) http://sprunge.us/OHjT   Intenso 'Class 10' 16GB (already used some time) http://sprunge.us/LUMZ   Intenso 'Class 4' 4GB (already used some time) http://sprunge.us/GbAY   Some updates from Igor (still showing superiour EVO results but the clear winner is ODROID's eMMC module with SD card adapter):   Transcend Premium 300x 16GB (almost new) http://sprunge.us/UcSD  
     
     
    Sandisk Extreme Pro 8Gb (almost new) http://sprunge.us/aDJJ
     
     
     
    Hardkernel eMMC 8G via SD reader (brand new) http://sprunge.us/SHXF
     
     
     
    Sandisk Ultra 8Gb (old and very used) http://sprunge.us/OWZf
     
     
     
    Sandisk 8GB (almost new) http://sprunge.us/iViT
     
     
     
    Sandisk 8G (new) http://sprunge.us/XHjj
     
     
     
    Transcend 8Gb (used) http://sprunge.us/NTRT
     
     
     
    Samsung EVO 32Gb (brand new) http://sprunge.us/bTQh
     
     
        Further readings: http://www.bunniestudios.com/blog/?page_id=1022 http://thewirecutter.com/reviews/best-microsd-card/ http://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-pi-microsd-card http://www.bradfordembedded.com/2014/05/flashbenching/ Conclusions:
    If the board's SD card interface is the bottleneck since it's not supporting the faster SDIO modes using expensive cards that exceed the interface's maximum sequential bandwidth is useless. An expensive Samsung Pro Plus won't be faster than a way more cheap EVO when it's about sequential transfer speeds since you will stay at ~22MB/s anyway Sequential read and especially write speeds are all the SD association's speed ratings are about (to ensure reliable recording of videos/images in cameras/recorders) When an SD card is used in an SBC sequential speeds aren't that important. It's all about random I/O, especially with small block sizes (reading and writing small random chunks of data from/to the card) No commonly used 'random I/O' speed ratings exist so you have to check the card in question prior to usage or rely on appropriate benchmarks (see the two links directly above). Again: the 'speed class' won't tell you anything. You can get two different 'class 10' cards that differ by 500% or even more regarding real world storage performance (again: random I/O matters). In the example above the Intenso 'class 10' card is 385 slower compared to the EVOs when it's about 16K random writes (good luck if you have a database running that uses this page size) Interestingly more expensive cards are outperformed by cheaper ones (the EVOs show a better overall performance compared to the Samsung Pro since sequential speeds are limited by the interface) One extreme example: Using an identical cloned installation that was somewhat outdated on the small 4GB Intenso card and on the 64GB EVO resulted in the following times for an 'apt-get upgrade' (+200 packages): EVO less than 6 minutes vs. 390 minutes (yes, ~6.5 hours) with the Intenso. The time to finish depends largely on fast random writes. It's easy to test the card in question when running Armbian since we ship with iozone. Therefore simply execute the iozone call from the first paragraph after logging in as a normal user. Starting with Armbian 5.06 a even better method exists that also tests the whole card for errors: armbianmonitor -c will report precisely both performance and health state of your card
  4. Like
    sysitos got a reaction from Gravelrash in 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
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines