Category Archives: Blog

Results of the Core Meeting

Photo by Levin on Unsplash

On the weekend we had a core meeting of siduction devs to talk about the future of the distribution. Proposed goals were the lessening of the workload, specialy for our main dev Alf (agaida) and more frequent releases. Other than that we had the revival of the siduction manual on the menu (which was in fact a fork of the excellent Bluewater Manual from the sidux days).

Lessen the workload

When it comes to lightening the workload, the only feasable way is to cut down on the number of images we produce. Reason for that is that some of the desktop enviromnents we ship have had no maintainer for a while. For the next release (which is not far away), we stop releasing images for the desktop environments GNOME, MATE and LXDE. That leaves us with images for KDE Plasma, Xfce, Cinnamon and LXQt. We also keep releasing the minimal entry points noX and Xorg.

That does not mean, users cannot use the desktops we dropped anymore. They are still available in the archives. We just stop customizing and producing images dedicated to them.

Advanced CI and CD

Besides that we will try to advance our Continuous Integreation and Delivery provided by Jenkins to churn out automated builds on a daily or weeky basis (no details decided yet) and make succesful builds available to our users. These builds will only be marginally tested, but we will make sure they boot correctly and the installer is in usable shape. These images will mostly work correctly, but are no replacement for the approved official releases. We have not yet decided, how these will be made available to you, but a dedicated forum section might be the easiest way.

Not a small feat

The siduction manual in it’s recent formfactor has been unmaintainable for a while now. Also some of the information in there is deprecated or needs to be adjusted. We plan to move the formfactor from (partialy badly written) HTML to Markdown (MD). Both of these tasks will have to be done manual and in conjunction in order not to move stuff to MD that will get kicked out afterwards. Once that is done, we will present the manual on a new platform that can turn MD into a visualy pleasing, easy to use and to maintain format. Volunteers wanted!

Artists in dire demand

Besided that we will be working on stabilizing the artwork in a way where it scales more correctly on all possible resolutions. Unless somebody with skills in the fine arts volunteers to supply us with artwork per release we will have to stick to what we are using now (which I find totaly acceptable) .

Contributors, step up

That being said, we have been keeping siduction rolling since 2011 with a small and more or less stable team and the support of you guys. What we would need is a stronger dev team to be able to work on new ideas and projects. So if you feel intrigued by working on the edge, come to IRC and talk to us. You do not need to be a software developer. We would love to have people with skills in art, translations, web-developement and maintainance, or just people with a passion for debian and siduction. We will for sure find something to do for you.

Last but not least we will try to get a booth at FROSCon 2019 in August, which is held in Siegburg, close to the German city of Bonn.

Core-Team Meeting in Berlin

Photo by Ricardo Gomez Angel on Unsplash

Tomorrow, on March 30, the siduction core team meets in Berlin to do some brain storming about the future of siduction. There will be five participants: Alf (agaida). Axel (ab), Torsten (towo), Markus (coruja) and me (devil). Topics will be a release plan that involves less work, a way to revive the manual in a different form factor and ways to spread siduction to more users.

Anyone that is in Berlin on the weekend is invited to join in. We will be at Coffee Fellows from 14:00 to ~ 18:00UTC/GMT +1 hour. There is an offfice space on the first floor, where you can find us. You can also participate via IRC in that time frame, if you have suggestions or questions for us. your link into our channels is on your desktop.

Next release plans

We are planning™ to release a full set of siduction images with all flavours before going to CLT (Chemnitzer Linux-Tage) next month. There are at least three reasons for that:

  • We can boast about it at the conference
  • We will have a new installer for you to try
  • We promised to do so

And here are the gory details: Six years ago we thought it would be a cool idea to have our installer running in a browser with the help of a tiny http server. Today for some reasons we do not think it is quite that cool. One of the reasons for that being the fact, that the guy who initialy wrote the installer is not available anymore.

Then, about three years ago someone by the name of Teo Mrnjavac had a marvelous idea, that will, similar to systemd, unify linux in a in my humble opinion positive way. I am talking about the Calamares Installer Framework. As you can see at the bottom of their webpage, your favorite distro is listed there already. It is used more and more by distributions and every one of them makes the code better. Sharing one installer eases a lot of problems for smaller distributions. The partitioning is done by KDE’s partition manager. What it does not do yet is LVM and RAID, but those are in the pipeline. Also, Calamares will make it’s way into Debian soon.

So for the past weeks that is what we have been working on. Calamares is C++, Qt 5 for the user interface and python modules to pick what you need and configure to your liking. Then apply a branding and you are done. Of course this was the fast-forward-mode, but we managed to get it up and running in less than two weeks. We are doing more testing to make sure it lives up to it’s reputation with siduction as well.

It also works fine with BIOS and UEFI, which kills another problem for us: The integration of UEFI in the old installer was far from perfect and included manual setup work before starting the installer. Given that we do not run into any blockers with the installer, we are confident that the freeze for Debian GNU/Linux 9 »Stretch« will allow us a release of all flavours without too many problems.

We also plan to make this next release our first release with 64-bit only. Yep, we think the time is right to drop the 32-bit plattform without making too many users unhappy. Should you be one of those not happy with our plan, please let us know your reasons on our forum. If you have a good reason to still run 32-bit, you might even be able to talk us into a custom build. But overall, dropping this architecture saves us a lot of time that can be better spent elsewhere.

Flatpak with siduction

Yesterday I wrote about how to install and use Snap to install the latest LibreOffice 5.3. I promised to do the same with Fedora/GNOME’s alternative package format Flatpak. Needless to say this also applies for pure Debian Unstable and Debian Testing installs. For Debian Jessie you would need backports enabled. For yesterdays post on Snap, the same goes for Unstable and Testing, whereas Jessie is left out in the rain for now.

Even though there is no flatpak for the latest version 5.3 of LibreOffice yet, we will install LO 5.2.5, which then can be updated to 5.3 in a few hours or days. Setting the base framework for flatpak is a little more work as you have to install the basic runtime (at least on a KDE system, maybe it comes automaticaly with a GNOME install. OK, lets get started withthe package itself:
# apt install flatpak
Now we need to get the runtime:
$ wget https://sdk.gnome.org/keys/gnome-sdk.gpg
$ flatpak remote-add --user --gpg-import=gnome-sdk.gpg gnome https://sdk.gnome.org/repo/
$ flatpak install --user gnome org.gnome.Platform 3.20

Now you can download the flatpak package for Libreoffice from the Flatpak-Apps page. Move to the directory where the download landed and install it:
$ flatpak install --user --bundle LibreOffice.flatpak
When that is done, you can start LO from the same directory by running:
$ flatpak run org.libreoffice.LibreOffice

Updates can be performed by running:
$ flatpak update --user org.libreoffice.LibreOffice

These alternate packaging formats are ideal for installing software that is not (yet) available in your distribution or versions not yet available, like LO 5.3 in our example. Developers can install different versions of a software that do not interfer with each other for testing. Which one of the new self-contained package formats (there is also Appimage) you prefer is totaly up to you. They offer a sandboxing model that is supposed the keep them separated from the environment. In the case of Flatpak they can talk to each other by means of Flatpak Portals.

Snaps with siduction

I am sure, everyone has heard about Ubuntu’s new package format snap by now. Today I wanted to try the brand new and still hot off the press LibreOffice 5.3 for a review. So I found that the Document Foundation had a snap ready for deployment. The prerequisites for siduction are not many:
# apt update && apt install snapd
After that, you can check, which snaps are avaialable for LibreOffice with:
$ snap info libreoffice
As you can see, the new version 5.3 is in the edge-channel. That is all you need to know to install it with:
# snap install libreoffice --channel=edge
Afterwards a repeated
$ snap info libreoffice
will reflect the installed packages. As you might have a version of LibreOffice already installed through your package manager, you will need to start the snap, using the full path:
$ /snap/bin/libreoffice &
Later on you can refresh them with
$ snap refresh libreoffice

Just a day or two ago, the first snaps of KDE apps turned up in the KDE-Store Tomorrow I will give flatpak, the alternative new package format by Fedora a try with libreoffice. You can read the results here tomorrow

New fast siduction mirror in the US

As of today we are happy to share with you a new mirror in the United States. It is located at Princeton University and should be our fastest mirror in the US.
The URLs are:

  • Princeton University

    http://mirror.math.princeton.edu/pub/siduction/iso/
    https://mirror.math.princeton.edu/pub/siduction/iso/
    deb https://mirror.math.princeton.edu/pub/siduction/extra unstable main
    deb-src https://mirror.math.princeton.edu/pub/siduction/extra unstable main
    deb https://mirror.math.princeton.edu/pub/siduction/fixes unstable main contrib non-free
    deb-src https://mirror.math.princeton.edu/pub/siduction/fixes unstable main contrib non-free

  • Direct links are to be found on our website.
    Please let us know if any problems arise.

    Structural changes coming up

    As you may have sensed by now, we are having problems this year getting out a proper release of the desktop environments we ship. There is more than one reason for that. For one it was really hard to get things in shape for a release. KDE for example was in heavy developement most of the time. Now that we have Plasma 5.8.x with longtime support, things settle down a bit and we will hopefuly get a release of that flavour out until the end of the year. GNOME and Cinnamon are also in steady movement, Xfce and MATE don’t move that much.

    On the other hand the time that siduction team members have at their hands have lessened over time. Speaking for myself, my workload has grown a lot during the past two years. Another team member joined a team that took on the job to bring LXQt in shape and into Debian (and they succeeded). A third team member got himself a job whereas before he was unemployed for some time (and of course we are happy for him). All these constraints make it harder to achieve our goals of releasing siduction in the way we did until now. That does not mean in any way that siduction is unmaintained. We steadily work on it as is needed and try to guide you through shallow waters. Just the big tasks like releases get left behind.

    There were no new contributors joining the team, so that does not help either. So we have come up with an idea that will lessen our workload a bit. The idea is for flavour maintainers to determine when a flavour is good and ready for release. We know in advance what is going to happen in critical flavours and if there is transitions or other big changes coming up, that might brake things. So, e.g. when KDE seems in good shape to be released to the public, so may be another flavour. Then those two could go out as a snapshot. Possibly a month later some other flavours are good to go.

    We found a long time contributor, who is willing to manage these kind of releases. That means checking if the flavour(s) are in releasable shape, coordinate a release and ship them on their way to you. That will help us and our users. You as a user get fresher snapshots as entry points to the distribution, which also attracts new users. For us as the team behind siduction it raises the visibility of the distribution, which also attracts new users and maybe even contributors. So we will give this a try and see how it goes. Like I said before, we hope to get results out before the end of the year.

    One other thing that is in dire need of love is our manual. Once a wealth of knowledge, it is now vastly aging and mostly unmaintained. The way it is technicaly set up makes it hard to contribute to and very unwieldy for us to maintain the infrastructure. There is two things to do here: We need to do the heavy lifting of transferring the content to a multilingual wiki like MediaWiki. We have languages in the manual, that are totaly unmaintained because noone in the team speaks the language (nor has the time) to work on these. Those languages are Portugese, Italian, Romanian, and Polish. We still need to decide what to do with them. Right now they are counterproductive because in parts they are by now plain wrong or misleasing. My idea is to archive them until maybe someone later picks up a language.

    The second task is to go over all German and English items in the manual and correct them where needed and bring them up to current, also write new ones (e.g. for systemd). All this needs manpower. So if you would like to help with any of this, you are very welcome, please reach out to us on our forum or on IRC on the OFTC network in #siduction-core. Working over the manual can be done as your time allows, there is no ETA to this. We are also always looking for artists. This is also a commitment that does not take up much of your time, it is mostly about creating an icon here and there.

    Debian fell over

    With systemd 230, released a couple of days ago, the developers changed a default setting, that eliminates one of the few annoyances I experienced with systemd. Many a forum thread all over the net tried to solve the problem. This annoyance resulted in a message during reboot or shutdown, that the system is waiting for a process to shut down. This could take up to 90 seconds, if you did not set the level lower manually. These were stray background processes, that belonged to one or more users on the system and should have been shut down, when the owning user gets logged out.

    The systemd developers with systemd 230 set the option KillUserProcesses in /etc/systemd/logind.conf to yes. That means that 95 percent of desktop users will not see these delays anymore, because all processes of a user will be closed when the user gets logged out. On the other hand, users of tools like screen, tmux and some others will find their processes also killed server-side, even though these were meant to be long-running background jobs. That being said, the devs did explain in the release note for systemd 230 under the third bullet, what users of such tools need to do to keep KillUserProcesses on yes and still have their long-running jobs stay alive. The problem at hand was being layed out in detail in a bugreport and it’s follow-up discussion already in April.

    In Debian and Fedora this new behaviour led to long discussions (and the usual systemd laments of course). The bug report for Debian on this matter now led to the new standard setting being reverted in Debian with systemd 230-2 as of today. So, if you like your processes being stopped when your user logs out, you need to manualy revert the setting in /etc/systemd/logind.conf to yes again after updating to systemd 230-2. We decided months ago to have this set to yes as default for siduction. This will take effect with our next release. But if you want to set this to yes now, you need to do so yourself.

    Should you be one of the users of screen, tmux, mosh and maybe a few other affected tools, there is ways to keep the setting at yes and still keep long running processes alive when logging out. You need two things to do this: first you set enable-linger [USER1 USER2...] for your respective users, as shown in the manpage to loginctl. PAM has been adapted to allow this as normal user. Then you can follow the manpage of systemd-run to start e.g. screen with the command systemd-run --scope --user screen in it’s own scope. This will keep the job running after logout, even though other user processes are stopped.

    We admired Debian for deciding pro systemd, but we think, reverting this new default is the wrong decision in the face of desktop users.

    Fun weekend at CLT Linux Conference

    Photo by Christian Bär, CC BY-NC-SA 2.0 Six siductioneers spent the last weekend at CLT 2015, the annual Linux conference at Chemnitz University. First of all, let me thank the people who organized this conference for the 17th time and of course all the helper bees that make it the most pleasant event on the annual Linux calendar. Just to give you an idea, here is some numbers. Besides a lot of workshops, more than 90 talks on a wide variety of subjects were held, 60 projects like siduction could exhibit the soft- or hardware or the services they offer. Between the two days of work and hacking, Linux-Night offers socialising, food, drink and music. It was nice to see that the place was packed and bursting at the seams with visitors on both days.

    We had a successful weekend and tons of fun. Besides answering questions or solving problems of visitors at our booth we were able to roll out some ideas for the future of siduction that you will learn about soon. Besides that we were paid a visit by some people from the distant past of our project. Klaus Knopper and also Kano from Kanotix came by our booth to say hello. Knopper was doing some inquiry on how to tame systemd for Knoppix, which is not all that easy due to the nature of the scripted way in which Knoppix boots. We were able to provide some help and advice here and put aside some of his worries in that regard. Both of them might be helpful to us in porting siduction to ARM devices. We supplied Kano with a developer board where he can play with porting stuff from other architectures. So with Knopper and Kano there and our pals from Debian right next to us, we had the full circle from the Knoppix/Kanotix origins to Debian Stable and beyond to the save haven of siduction.

    Besides that we managed to talk to our server provider Hetzner, whose company was also present with a booth. They will upgrade our hardware for web- and buildserver in the course of 2015 free of cost and for the same fee as we pay now. We also worked on some ideas on how to attract new developers to siduction, which is a problem that in the long run we will need to solve for sure. Too much work is on just a few shoulders right now. Things we need to attack soon involve UEFI installs and, regarding the latest news from linux-loving Microsoft, we might have to deal with secure boot as well. One of the ideas to attract new blood is to rent another server and donate slices of that to developers and projects who need some iron to work on for a fixed time frame. Our terms for this would be, that people who want to use our offer at least have a look at our project and consider a list of problems we want to tackle and help a bit with that, if they can.

    What we did not do on this weekend was taking pictures. I left my camera at home and noone else had one either. So this article has the only photo of our booth that I could find on the net. But that is ok, facts are more important than pics :). Some Debian folks invited us to DebConf, which is held in August for the first time in Germany. Besides that we will visit another young Linux fair called Open-Rhein-Ruhr and that takes place in November in the city of Oberhausen.

    Revisting an article on how to set up Solid State Disks with Linux

    Almost three years ago I wrote a lengthy article on how to align, partition, configure and benchmark Solid State Disks under Linux. Those were the early days of these NAND flash memory devices and you had to jump through some hoops to get them to perform at their best when it comes to performance and durability. So by now parts of the tutorial have been obsolete for some time now. Graphical partitioning tools e.g. handle the alignment of these devices correctly nowadays, which they did not do back then. I have never found the time to go back to that article and bring it up to the latest.

    So we are grateful, that Don, who on the forum goes as dibl, took it upon him to present us with a modernised version of this tutorial. Not only does he eliminate cruft that is obsolete or plain wrong nowadays, he also describes a different concept of trimming these devices. This method substitutes the discard parameter in your fstab, that takes care of the trimming for most of us. This method makes use of the fstrim command from the package util-linux, which, which is run, preferably when you are absent from the machine, by a script using cron on a daily or weekly turn. This prevents that discard calls TRIM every time we delete a file and slow things down. So, here we go, thanks again, Don.

    Optimizing SSD-based System Performance

    The goal of these configuration settings, generally, is to select and configure a suitable filesystem, to minimize erase/write cycles that don’t add to system performance, to enable TRIM, and otherwise to optimize the OS to provide a very responsive user experience.

    1. Filesystem type and /etc/fstab configuration

    We want to use ext4 and take advantage of the journaling feature, for data security, but we want to reduce the frequency of journal commits (writes to the SSD) from the default 5 seconds to a slower rate, to extend the life of the SSD memory blocks. The “commit” mount option controls the frequency of journal commits, and as mentioned is set to 5 seconds by default. Understanding that slowing down this frequency also raises the risk of data lost in a power loss or system freeze situation, choose a slower frequency that you are comfortable with, like “120” for two minutes, a reduction of 24x. To avoid writes caused only by reading files, use the “noatime” option. As a result, the /etc/fstab line that mounts the OS will look like this:

    UUID=bea3a748-3411-4024-acd0-39f3882ddaf9 / ext4 noatime,commit=120,errors=remount-ro 0 1

    For typical laptop and single-user computers, we want to mount selected filesystems as “tmpfs”, which lets the OS use memory rather than the SSD for logging and spooling. The wise user will wait for a reasonable period of time after initially installing on the SSD, before these changes are made to /etc/fstab, because until you are sure your system is stable, you should allow the logs to be written on the SSD, for later review. Logs written in memory will not survive a reboot. When you are satisfied that the system is stable and the logs can safely be lost at each reboot, add these lines to the end of /etc/fstab:

    none /tmp tmpfs defaults,noatime,mode=1777 0 0
    none /var/tmp tmpfs defaults,noatime 0 0
    none /var/log tmpfs defaults,noatime 0 0
    none /var/spool tmpfs defaults,noatime 0 0

    Alternatively, you could mount these directories on a hard disk drive if one is also installed in the system – a better approach for a server, for example, where you might need to periodically review older logs.

    2. Enable TRIM

    Recent guidance [4] recommends using the fstrim utility periodically, rather than using the “discard” filesystem mount option. At the conclusion of the linked blog, a very handy script for use as a cron job is shown, and it is repeated here for convenience:

    #!/bin/sh
    #
    # To find which FS support trim, we check that DISC-MAX (discard max bytes)
    # is greater than zero. Check discard_max_bytes documentation at
    # https://www.kernel.org/doc/Documentation/block/queue-sysfs.txt
    #
    for fs in $(lsblk -o MOUNTPOINT,DISC-MAX,FSTYPE | grep -E '^/.* [1-9]+.* ' | awk '{print $1}'); do
    fstrim "$fs"
    done

    Save it as /etc/cron.weekly/fstrim_job.

    Note that LVM systems and LUKS/dm encrypted filesystems add additional configuration tasks to the basic filesystem configuration described here – follow the guidance to enable TRIM at each level of your system configuration.

    3. Outsource the browser cache to /run/user (guidance for single-user system, can be expanded for multi-user implementation)

    Since Debian now has the shared directory /run/user/usernumber in RAM, we can outsource the cache generated during browsing to memory, and eliminate many SSD writes. For example, in the Firefox/Iceweasel address bar we enter “about:config” and confirm the warning. Now right-click in the white space and choose “New ==> String” and we create a new entry called:

    browser.cache.disk.parent_directory

    After double-clicking the new string, we assign it the value:

    /run/user/1000/firefox-cache for the first user.

    Now as user in the terminal create a directory:

    mkdir -p /run/user/1000/firefox-cache

    After a Firefox restart, browser caching happens in memory, not on the SSD.

    For chromium-browser, the cache location is set with the --disk-cache-dir=”DIRNAME launch command option. So to outsource the chromium-browser cache:

    mkdir -p /run/user/1000/chromium-cache

    Open the chromium-browser launch icon for editing, change to the »Application« tab, and edit the start command to read as follows:

    /usr/bin/chromium –disk-cache-dir=/run/user/1000/chromium-cache %U

    In /usr/share/applications/chromium.desktop, find the line

    Exec=/usr/bin/chromium %U

    and edit it to read

    Exec=/usr/bin/chromium –disk-cache-dir=/run/user/1000/chromium-cache %U.

    Note that this will need to be done again after each chromium package update overwrites it.

    The new browser cache directory in /run/user will not survive a reboot. To automate this process, put the following “auto_browser_cache.sh” script in your ~.kde/Autostart folder (for KDE users), and then chmod +x to make it executable:

    #!/bin/bash
    NEWDIR=/run/user/1000/chromium-cache
    mkdir -p "$NEWDIR" &
    sleep 1
    NEWDIR1=/run/user/1000/firefox-cache
    mkdir -p "$NEWDIR1" &
    sleep 1
    #end

    Analogous cache outsourcing configuration can be made for other browsers, if they allow the user to specify the cache location, and the startup script can be adapted to add directories for each browser that the user wants to run.

    For a desktop system that remains booted for long periods, and depending on the memory capacity and browsing activities, the outsourced browsing cache could grow to a problematic size and need to be manually cleared to avoid sending the system into swapping.

    4. I/O Scheduler selection

    Multiple sources that you can find with a google search indicate that, for SSDs, the “deadline” and “noop” schedulers perform better than the default “cfq” scheduler, with deadline getting the most recommendations. Set the scheduler in /etc/sysfs.conf as so:

    block/sda/queue/scheduler=deadline

    5. Virtual memory settings

    Depending on how much memory your system has, and how you use it, the same tweaks to vm (swappiness, vfs_cache_pressure, etc.) that you use for a hard disk drive installation can also be applied to a system installed on a SSD. Guidance is available via google search as well as the two excellent references below. Here are the lines added to /etc/sysctl.d/sysctl.conf on one of my SSD installations:

    vm.swappiness=1
    vm.vfs_cache_pressure=25
    vm.dirty_ratio = 50
    vm.dirty_background_ratio = 3
    #

    Virtual Memory Tuning References:

    http://www.westnet.com/~gsmith/content/linux-pdflush.htm

    http://www.cyberciti.biz/faq/linux-kernel-tuning-virtual-memory-subsystem/

     

    Performance Testing (from devil’s article)

    Before you spend time on performance testing and benchmarking your SSD, you need to determine the firmware version you have, and then check the OEM’s website and learn whether a more recent version is available. Significant performance improvements can result merely from updating your SSD firmware — follow your OEM’s instruction to install updated firmware. To check your firmware version:

    hdparm -iv /dev/sdx

    6. Verify that TRIM is working (after setting the “discard” mount option as shown in #1 above).

    # cd to some directory on the SSD, then
    dd if = /dev/urandom of=tempfile bs=512k count=100 oflag=direct
    hdparm - fibmap tempfile

    # here we read the sectors from the tempfile

    From the output we copy the number immediately under “begin_LBA” and insert it in the next command:
    hdparm - read-sector 1234567 /dev/sdx
    # 1234567 replaced with the number from the previous command and /dev/sdx with your device ID

    The output should be a longer string. Next:

    rm tempfile
    sync
    hdparm -read-sector 1234567 /dev/sdx

    # replace 1234567 and /dev/sdx with your values

    The sectors will not be cleared instantly due to caching — wait for some seconds. Then repeat the last command (hdparm – read-sector …) — it should (after a short while) come out all zeros. That means TRIM works! If you have problems with “discard” on your SSD and you have verified that your SSD does support TRIM, you can use fstrim which is in the current util-linux package (check “man fstrim”), or use the tool “DiskTrim” from http://disktrim.sourceforge.net/.

    7. Throughput Benchmarking

    CAUTION: You can benchmark your SSD to a premature death by subjecting it to frequent comprehensive benchmark tests!

    7a. Simple hdparm test:

    hdparm -tT /dev/sdx

    Run it twice in rapid succession — normally the second run is fastest.

    7b. hdparm with O_DIRECT kernel flag:

    hdparm --direct -tT /dev/sdx

    7c. More reliable benchmark using dd:

    # cd to some directory on the SSD, then
    $ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync, notrunc
    1024 +0 records in
    1024 +0 records out
    1073741824 bytes (1.1 GB) copied, 2.18232 s, 492 Mb/s

    Now (as root) clear the buffer cache to force reading directly from disk:
    # echo 3 > /proc/sys/vm/drop_caches
    $ tempfile dd if=of=/dev/null bs=1M count=1024
    1024 +0 records in
    1024 +0 records out
    1073741824 bytes (1.1 GB) copied, 2 , 55234 s, 421 Mb/s

    Now we have the last file in the buffer cache and measure its speed:
    $ dd if=tempfile of=/dev/null bs=1M count=1024
    1024 +0 records in
    1024 +0 records out
    1073741824 bytes (1.1 GB) copied, 0.122594 s, 8.8 Gb/s

    For the most accurate possible value for your SSD, re-run the last command 5 times and average the results.

    7d. Other benchmarking tools are bonnie++ and compilebench. Have fun!

    REFERENCES:

    [1] Debian Wiki https://wiki.debian.org/SSDOptimization

    [2] Arch Wiki https://wiki.archlinux.org/index.php/Solid_State_Drives

    [3] SSD Endurance Testing http://techreport.com/review/25889/the-ssd-endurance-experiment-500tb-update

    [4] Trim Guidance http://blog.neutrino.es/2013/howto-properly-activate-trim-for-your-ssd-on-linux-fstrim-lvm-and-dmcrypt/