https://wiki.archlinux.org/api.php?action=feedcontributions&user=Kritztopf&feedformat=atomArchWiki - User contributions [en]2024-03-28T14:09:29ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Solid_state_drive&diff=348279Solid state drive2014-12-05T10:38:33Z<p>Kritztopf: Added more current links of the SSD Endurance test from TechCrunch. 2 Petabytes and still going.</p>
<hr />
<div>[[Category:Storage]]<br />
[[it:Solid State Drives]]<br />
[[ja:Solid State Drives]]<br />
[[ru:Solid State Drives]]<br />
[[zh-CN:Solid State Drives]]<br />
[[zh-TW:Solid State Drives]]<br />
{{Related articles start}}<br />
{{Related|SSD Benchmarking}}<br />
{{Related|SSD Memory Cell Clearing}}<br />
{{Related|profile-sync-daemon}}<br />
{{Related articles end}}<br />
<br />
This article covers many aspects of SSDs (solid state drives) as they relate to Linux; however, the underlying principles and key learning presented within are general enough to be applicable to users running SSDs on other operating systems such as the Windows family of products as well as Mac OS X. Beyond the aforementioned information, Linux users will benefit from the tweaks/optimization presented herein.<br />
<br />
==Overview==<br />
<br />
===Introduction===<br />
<br />
Solid State Drives (SSDs) are not PnP devices. Special considerations such as partition alignment, choice of file system, TRIM support, etc. are needed to set up SSDs for optimal performance. This article attempts to capture referenced, key learnings to enable users to get the most out of SSDs under Linux. Users are encouraged to read this article in its entirety before acting on recommendations as the content is organized by topic, not necessarily by any systematic or chronologically relevant order.<br />
<br />
{{Note|This article is targeted at users running Linux, but much of the content is also relevant to our friends using other operating systems like BSD, Mac OS X or Windows.}}<br />
<br />
===Advantages over HDDs===<br />
<br />
*Fast read speeds - 2-3x faster than modern desktop HDDs (7,200 RPM using SATA2 interface).<br />
*Sustained read speeds - no decrease in read speed across the entirety of the device. HDD performance tapers off as the drive heads move from the outer edges to the center of HDD platters.<br />
*Minimal access time - approximately 100x faster than an HDD. For example, 0.1 ms (100 us) vs. 12-20 ms (12,000-20,000 us) for desktop HDDs.<br />
*High degree of reliability.<br />
*No moving parts.<br />
*Minimal heat production.<br />
*Minimal power consumption - fractions of a W at idle and 1-2 W while reading/writing vs. 10-30 W for a HDD depending on RPMs.<br />
*Light-weight - ideal for laptops.<br />
<br />
===Limitations===<br />
<br />
*Per-storage cost (close to a dollar per GB, vs. around a dime or two per GB for rotating media).<br />
*Capacity of marketed models is lower than that of HDDs.<br />
*Large cells require different filesystem optimizations than rotating media. The flash translation layer hides the raw flash access which a modern OS could use to optimize access.<br />
*Partitions and filesystems need some SSD-specific tuning. Page size and erase page size are not autodetected.<br />
*Cells wear out. Consumer MLC cells at mature 50nm processes can handle 10000 writes each; 35nm generally handles 5000 writes, and 25nm 3000 (smaller being higher density and cheaper). If writes are properly spread out, are not too small, and align well with cells, this translates into a lifetime write volume for the SSD that is a multiple of its capacity. Daily write volumes have to be balanced against life expectancy. However, tests [http://techreport.com/review/25889/the-ssd-endurance-experiment-500tb-update][http://techreport.com/review/26523/the-ssd-endurance-experiment-casualties-on-the-way-to-a-petabyte][http://techreport.com/review/27436/the-ssd-endurance-experiment-two-freaking-petabytes] performed on recent hardware suggest that SSD wear is negligible, with the lifetime expectancy of SSDs comparable to those of HDDs even with artificially high write-volumes.<br />
*Firmwares and controllers are complex. They occasionally have bugs. Modern ones consume power comparable with HDDs. They [https://lwn.net/Articles/353411/ implement] the equivalent of a log-structured filesystem with garbage collection. They translate SATA commands traditionally intended for rotating media. Some of them do on the fly compression. They spread out repeated writes across the entire area of the flash, to prevent wearing out some cells prematurely. They also coalesce writes together so that small writes are not amplified into as many erase cycles of large cells. Finally they move cells containing data so that the cell does not lose its contents over time.<br />
*Performance can drop as the disk gets filled. Garbage collection is not universally well implemented, meaning freed space is not always collected into entirely free cells.<br />
<br />
===Pre-Purchase Considerations===<br />
<br />
There are several key features to look for prior to purchasing a contemporary SSD.<br />
*Native [[wikipedia:TRIM|TRIM]] support is a vital feature that both prolongs SSD lifetime and reduces loss of performance for write operations over time.<br />
*Buying the right sized SSD is key. As with all filesystems, target <75 % occupancy for all SSD partitions to ensure efficient use by the kernel.<br />
<br />
==Tips for Maximizing SSD Performance==<br />
=== Partition alignment ===<br />
<br />
See [[Partitioning#Partition alignment]].<br />
<br />
=== TRIM ===<br />
<br />
Most SSDs support the [[wikipedia:TRIM|ATA_TRIM command]] for sustained long-term performance and wear-leveling. For more including some before and after benchmark, see [https://sites.google.com/site/lightrush/random-1/howtoconfigureext4toenabletrimforssdsonubuntu this] tutorial. <br />
<br />
As of linux kernel version 3.7, the following filesystems support TRIM: [[Ext4]], [[Btrfs]], [[JFS]], VFAT, [[XFS]].<br />
<br />
VFAT only supports TRIM by Mount Flag 'discard', not by fstrim.<br />
<br />
The [[#Choice of Filesystem|Choice of Filesystem]] section of this article offers more details.<br />
<br />
==== Verify TRIM Support ====<br />
<br />
# hdparm -I /dev/sda | grep TRIM<br />
* Data Set Management TRIM supported (limit 1 block)<br />
* Deterministic read data after TRIM<br />
<br />
To have a better understanding of "limit 1 block" or "limit 8 block", see [[wikipedia:TRIM#ATA]]<br />
<br />
==== Enable TRIM by Mount Flags ====<br />
<br />
Using this flag in one's {{ic|/etc/fstab}} enables the benefits of the TRIM command stated above.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,'''discard''' 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,'''discard''' 0 2<br />
<br />
{{Note|<br />
* TRIM is not by default activated when using block-device encryption on a SSD; for more information see [[Dm-crypt/Specialties#Discard.2FTRIM_support_for_solid_state_drives_.28SSD.29|Dm-crypt/TRIM support for SSD]].<br />
* There is no need for the {{ic|discard}} flag if you run {{ic|fstrim}} periodically.<br />
* Using the {{ic|discard}} flag for an ext3 root partition will result in it being mounted read-only.}}<br />
{{Warning|Users need to be certain that their SSD supports TRIM before attempting to mount a partition with the {{ic|discard}} flag. Data loss can occur otherwise!}}<br />
<br />
==== Apply TRIM via cron ====<br />
<br />
{{Note|This method does not work for VFAT filesystems.}}<br />
Enabling TRIM on supported SSDs is definitely recommended. But sometimes it may cause some SSDs to [https://patrick-nagel.net/blog/archives/337 perform slowly] during deletion of files. If this is the case, one may choose to use fstrim as an alternative.<br />
# fstrim -v /<br />
The partition for which fstrim is to be applied must be mounted, and must be indicated by the mount point. <br />
<br />
If this method seems like a better alternative, it might be a good idea to have this run from time to time using cron. To have this run daily, the default cron package ({{pkg|cronie}}) includes an anacron implementation which, by default, is set up for hourly, daily, weekly, and monthly jobs. Note that [[Cron#Activation_and_autostart|cronie systemd service]] is not enabled by default in new Arch installs. To add to the list of daily cron tasks, simply create a script that takes care of the desired actions and put it in {{ic|/etc/cron.daily}}, {{ic|/etc/cron.weekly}}, etc. Appropriate nice and ionice values are recommended if this method is chosen. If implemented, remove the {{ic|discard}} option from {{ic|/etc/fstab}}.<br />
<br />
{{Note|Use the {{ic|discard}} mount option as a first choice. This method should be considered second to the normal implementation of TRIM.}}<br />
<br />
==== Apply TRIM via a systemd service====<br />
<br />
The {{Pkg|util-linux}} package provides {{ic|fstrim.service}} and {{ic|fstrim.timer}} [[systemd]] unit files. [[systemd#Using units|Enabling]] the timer will activate the service weekly, which will then trim all mounted filesystems on devices that support the discard operation.<br />
<br />
==== Enable TRIM With tune2fs (Discouraged) ====<br />
<br />
One can set the trim flag statically with tune2fs:<br />
<br />
# tune2fs -o discard /dev/sd'''XY'''<br />
<br />
{{Warning|This method will cause the {{ic|discard}} option to [https://bbs.archlinux.org/viewtopic.php?id&#61;137314 not show up] with {{ic|mount}}.}}<br />
<br />
==== Enable TRIM for LVM ====<br />
<br />
Change the value of {{ic|issue_discards}} option from 0 to 1 in {{ic|/etc/lvm/lvm.conf}}.<br />
<br />
{{Note|Enabling this option will "issue discards to a logical volumes's underlying physical volume(s) when the logical volume is no longer using the physical volumes' space (e.g. lvremove, lvreduce, etc)" (see {{ic|man lvm.conf}} and/or inline comments in {{ic|/etc/lvm/lvm.conf}}). As such it does not seem to be required for "regular" TRIM requests (file deletions inside a filesystem) to be functional.}}<br />
<br />
==== Enable TRIM for dm-crypt ====<br />
<br />
{{Warning|The discard option allows discard requests to be passed through the encrypted block device. This improves performance on SSD storage but has security implications. See [[Dm-crypt/Specialties#Discard.2FTRIM_support_for_solid_state_drives_.28SSD.29|Dm-crypt/TRIM support for SSD]] for more information.}}<br />
<br />
For non-root filesystems, configure {{ic|/etc/crypttab}} to include {{ic|discard}} in the list of options for encrypted block devices located on a SSD (see [[Dm-crypt/System configuration#crypttab]]).<br />
<br />
For the root filesystem, follow the instructions from [[Dm-crypt/Specialties#Discard.2FTRIM_support_for_solid_state_drives_.28SSD.29|Dm-crypt/TRIM support for SSD]] to add the right kernel parameter to the bootloader configuration.<br />
<br />
=== I/O Scheduler ===<br />
<br />
Consider switching from the default [[wikipedia:CFQ|CFQ]] scheduler (Completely Fair Queuing) to [[wikipedia:NOOP_scheduler|NOOP]] or [[wikipedia:Deadline_scheduler|Deadline]]. The latter two offer performance boosts for SSDs. The NOOP scheduler, for example, implements a simple queue for all incoming I/O requests, without re-ordering and grouping the ones that are physically closer on the disk. On SSDs seek times are identical for all sectors, thus invalidating the need to re-order I/O queues based on them.<br />
<br />
The CFQ scheduler is enabled by default on Arch. Verify this by viewing the contents {{ic|/sys/block/sd'''X'''/queue/scheduler}}:<br />
<br />
{{hc|$ cat /sys/block/sd'''X'''/queue/scheduler|<br />
noop deadline [cfq]<br />
}}<br />
<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
Users can change this on the fly without the need to reboot with:<br />
<br />
# echo noop > /sys/block/sd'''X'''/queue/scheduler<br />
<br />
or:<br />
<br />
$ sudo tee /sys/block/sd'''X'''/queue/scheduler <<< noop<br />
<br />
This method is non-persistent (eg. change will be lost upon rebooting). Confirm the change was made by viewing the contents of the file again and ensuring "noop" is between brackets.<br />
<br />
==== Kernel parameter (for a single device) ====<br />
<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the {{ic|1=elevator=noop}} [[Kernel parameters|kernel parameter]].<br />
<br />
====Using udev for one device or HDD/SSD mixed environment====<br />
<br />
Though the above will undoubtedly work, it is probably considered a reliable workaround. Ergo, it would be preferred to use the system that is responsible for the devices in the first place to implement the scheduler. In this case it is udev, and to do this, all one needs is a simple [[udev]] rule.<br />
<br />
To do this, create the following:<br />
<br />
{{hc|/etc/udev/rules.d/60-schedulers.rules|<nowiki><br />
# set deadline scheduler for non-rotating disks<br />
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"<br />
<br />
</nowiki>}}<br />
<br />
Of course, set Deadline/CFQ to the desired schedulers. Changes should occur upon next boot. To check success of the new rule:<br />
<br />
$ cat /sys/block/sd'''X'''/queue/scheduler # where '''X''' is the device in question<br />
<br />
{{Note|In the example sixty is chosen because that is the number udev uses for its own persistent naming rules. Thus, it would seem that block devices are at this point able to be modified and this is a safe position for this particular rule. But the rule can be named anything so long as it ends in {{ic|.rules}}.)}}<br />
<br />
=== Swap Space on SSDs ===<br />
<br />
One can place a swap partition on an SSD. Most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature.<br />
<br />
A recommended tweak for SSDs using a swap partition is to reduce the [[Swap#Swappiness|swappiness]] of the system to some very low value (for example {{ic|1}}), and thus avoiding writes to swap.<br />
<br />
=== Hdparm shows "frozen" state ===<br />
<br />
Some motherboard BIOS' issue a "security freeze" command to attached storage devices on initialization. Likewise some SSD (and HDD) BIOS' are set to "security freeze" in the factory already. Both result in the device's password security settings to be set to '''frozen''', as shown in below output: <br />
<br />
{{hc|head=:~# hdparm -I /dev/sda |output=<br />
Security: <br />
Master password revision code = 65534<br />
supported<br />
not enabled<br />
'''not locked'''<br />
'''frozen'''<br />
not expired: security count<br />
supported: enhanced erase<br />
4min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT. }}<br />
<br />
Operations like formatting the device or installing operating systems are not affected by the "security freeze". <br />
<br />
The above output shows the device is '''not locked''' by a HDD-password on boot and the '''frozen''' state safeguards the device against malwares which may try to lock it by setting a password to it at runtime. <br />
<br />
If you intend to set a password to a "frozen" device yourself, a motherboard BIOS with support for it is required. A lot of notebooks have support, because it is required for [[Wikipedia:Hardware-based_full_disk_encryption|hardware encryption]], but support may not be trivial for a desktop/server board. For the Intel DH67CL/BL motherboard, for example, the motherboard has to be set to "maintenance mode" by a physical jumper to access the settings (see [http://sstahlman.blogspot.in/2014/07/hardware-fde-with-intel-ssd-330-on.html?showComment=1411193181867#c4579383928221016762], [https://communities.intel.com/message/251978#251978]). <br />
<br />
{{Warning|Do not try to change the above '''lock''' security settings with {{ic|hdparm}} unless you know exactly what you are doing.}}<br />
<br />
If you intend to erase the SSD, see [[Securely wipe disk#hdparm]] and [[#SSD_Memory_Cell_Clearing|below]].<br />
<br />
=== SSD Memory Cell Clearing ===<br />
<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time the device was installed thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
=== Resolving NCQ Errors ===<br />
<br />
Some SSDs and SATA chipsets do not work properly with Linux Native Command Queueing (NCQ). The tell-tale dmesg errors look like this:<br />
<br />
[ 9.115544] ata9: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x10 frozen<br />
[ 9.115550] ata9.00: failed command: READ FPDMA QUEUED<br />
[ 9.115556] ata9.00: cmd 60/04:00:d4:82:85/00:00:1f:00:00/40 tag 0 ncq 2048 in<br />
[ 9.115557] res 40/00:18:d3:82:85/00:00:1f:00:00/40 Emask 0x4 (timeout)<br />
<br />
These may be resolved by one of the following methods:<br />
<br />
# Update the firmware on the SSD. See [[SSD#Firmware_Updates]].<br />
# Update the BIOS/UEFI on the motherboard. See [[Flashing_BIOS_from_Linux]].<br />
# Disable NCQ on boot. Add {{ic|1=libata.force=noncq}} to the kernel command line in the [[Bootloader]] configuration.<br />
<br />
If these do not resolve the problem or cause other issues, [[Reporting_Bug_Guidelines | file a bug report]].<br />
<br />
== Tips for minimizing disk reads/writes ==<br />
<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification. Also compare [http://techreport.com/review/25889/the-ssd-endurance-experiment-500tb-update] when considering whether any particular strategy to limit disk writes is actually needed.}}<br />
<br />
Use {{Pkg|iotop}} and sort by disk writes to see how much and how frequently are programs writing to the disk.<br />
<br />
{{Tip|''iotop'' can be run in batch mode instead of the default interactive mode using the {{ic|-b}} option. {{ic|-o}} is used to show only processes actually doing I/O, and {{ic|-qqq}} is to suppress column names and I/O summary. See {{ic|man iotop}} for more options.<br />
# iotop -boqqq<br />
}}<br />
<br />
=== Intelligent partition scheme ===<br />
<br />
*For systems with both an SSD and an HDD, consider relocating the {{ic|/var}} partition to a magnetic disc on the system rather than on the SSD itself to avoid read/write wear.<br />
<br />
=== noatime mount option ===<br />
<br />
{{Merge|fstab#atime options|This should be described only in one place, just link to [[fstab]] afterwards.}}<br />
<br />
Using this flag in one's {{ic|/etc/fstab}} halts the logging of read accesses to the file system via an update to the atime information associated with the file. The importance of the {{ic|noatime}} setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains.<br />
<br />
{{Note|The write time information to a file will continue to be updated anytime the file is written to with this option enabled.}}<br />
<br />
/dev/sda1 / ext4 defaults,'''noatime''' 0 1<br />
/dev/sda2 /home ext4 defaults,'''noatime''' 0 2<br />
<br />
{{Note|This setting will cause issues with some programs such as [[Mutt]], as the access time of the file will eventually be previous than the modification time, which would make no sense. Using the {{ic|relatime}} option instead of {{ic|noatime}} will ensure that the atime field will never be prior to the last modification time of a file. Alternatively, using the maildir storage format also solves this mutt issue.}}<br />
<br />
=== Locate frequently used files to RAM ===<br />
<br />
==== Browser profiles ====<br />
<br />
One can ''easily'' mount browser profile(s) such as chromium, firefox, opera, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
The AUR contains several packages to automate this process, for example {{AUR|profile-sync-daemon}}.<br />
<br />
==== Others ====<br />
<br />
For the same reasons a browser's profile can be relocated to RAM, so can highly used directories such as {{ic|/srv/http}} (if running a web server). A sister project to {{AUR|profile-sync-daemon}} is {{AUR|anything-sync-daemon}}, which allows users to define '''any''' directory to sync to RAM using the same underlying logic and safe guards.<br />
<br />
=== Compiling in tmpfs ===<br />
<br />
Intentionally compiling in [[tmpfs]] is great to minimize disk reads/writes. For more information, refer to [[Makepkg#Improving_compile_times]].<br />
<br />
=== Disabling journaling on the filesystem ===<br />
<br />
Using a journaling filesystem such as ext4 on an SSD '''without''' a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://tytso.livejournal.com/61830.html Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with {{ic|noatime}}.'''<br />
<br />
{| class="wikitable"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in tmpfs as recommended in the [[#Compiling in tmpfs|preceding section]] of this article!}}<br />
<br />
== Choice of Filesystem ==<br />
<br />
=== Btrfs ===<br />
<br />
[[wikipedia:Btrfs|Btrfs]] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. Users are encouraged to read the [[Btrfs]] article for more info.<br />
<br />
=== Ext4 ===<br />
<br />
[[wikipedia:Ext4|Ext4]] is another filesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. ext4 users must explicitly enable the TRIM command support using the {{ic|discard}} mount option in [[fstab]] (or with {{ic|tune2fs -o discard /dev/sdaX}}).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/filesystems/ext4.txt official in kernel tree documentation] for further information on ext4.<br />
<br />
===XFS===<br />
<br />
Many users do not realize that in addition to ext4 and btrfs, [[wikipedia:XFS|XFS]] has TRIM support as well. This can be enabled in the usual ways. That is, the choice may be made of either using the discard option mentioned above, or by using the fstrim command. More information can be found on the [http://xfs.org/index.php/FITRIM/discard XFS wiki].<br />
<br />
===JFS===<br />
<br />
As of Linux kernel version 3.7, proper TRIM support has been added. So far, there is not a great wealth of information of the topic but it has certainly been picked up by [http://www.phoronix.com/scan.php?page=news_item&px=MTE5ODY Linux news sites.] It is apparent that it can be enabled via the {{ic|discard}} mount option, or by using the method of batch TRIMs with fstrim.<br />
<br />
===Other filesystems===<br />
<br />
There are other filesystems specifically [[wikipedia:List_of_flash_file_systems#File_systems_optimized_for_flash_memory.2C_solid_state_media|designed for SSD]], for example [[F2fs]].<br />
<br />
== Firmware Updates ==<br />
<br />
=== ADATA ===<br />
<br />
ADATA has a utility available for Linux (i686) on their support page [http://www.adata.com.tw/index.php?action=ss_main&page=ss_content_driver&lan=en here]. The link to latest firmware will appear after selecting the model. The latest Linux update utility is packed with firmware and needs to be run as root. One may need to set correct permissions for binary file first.<br />
<br />
===Crucial===<br />
<br />
Crucial provides an option for updating the firmware with an ISO image. These images can be found after selecting the product [http://www.crucial.com/support/firmware.aspx here] and downloading the "Manual Boot File." Owners of an M4 Crucial model, may check if a firmware upgrade is needed with {{ic|smartctl}}.<br />
<br />
{{hc|$ smartctl --all /dev/sd'''X'''|<br />
==> WARNING: This drive may hang after 5184 hours of power-on time:<br />
http://www.tomshardware.com/news/Crucial-m4-Firmware-BSOD,14544.html<br />
See the following web pages for firmware updates:<br />
http://www.crucial.com/support/firmware.aspx<br />
http://www.micron.com/products/solid-state-storage/client-ssd#software<br />
}}<br />
<br />
Users seeing this warning are advised to backup all sensible data and '''consider upgrading immediately'''.<br />
<br />
===Kingston===<br />
<br />
Kingston has a Linux utility to update the firmware of Sandforce controller based drives: [http://www.kingston.com/en/ssd SSD support page]. Click the images on the page to go to a support page for your SSD model. Support specifically for, e.g. the SH100S3 SSD, can be found here: [http://www.kingston.com/en/support/technical/downloads?product=sh100s3&filename=sh100_503fw_win support page].<br />
<br />
===Mushkin===<br />
<br />
The lesser known Mushkin brand Solid State drives also use Sandforce controllers, and have a Linux utility (nearly identical to Kingston's) to update the firmware.<br />
<br />
=== OCZ ===<br />
<br />
OCZ has a command line utility available for Linux (i686 and x86_64) on their forum [http://www.ocztechnology.com/ssd_tools/ here].<br />
<br />
===Samsung===<br />
<br />
Samsung notes that update methods other than by using their Magician Software is "not supported", but it is possible. Apparently the Magician Software can be used to make a USB drive bootable with the firmware update. The easiest method, though, is to use the bootable ISO images they provide for updating the firmware. They can be grabbed from [http://www.samsung.com/global/business/semiconductor/samsungssd/downloads.html here].<br />
<br />
{{Note|Samsung does not make it obvious at all that they actually provide these. They seem to have 4 different firmware update pages each referencing different ways of doing things.}}<br />
<br />
Users preferring to run the firmware update from a live USB-Stick created under Linux (without using Samsung's "Magician" software under Microsoft Windows), see [http://fomori.org/blog/?p=933 this post] for reference.<br />
<br />
=== SanDisk ===<br />
<br />
SanDisk makes '''ISO firmware images''' to allow SSD firmware update on operating systems that are unsupported by their SanDisk SSD Toolkit. One must choose the firmware for the right ''SSD model'', as well as for the ''capacity'' that it has (e.g. 60GB, '''or''' 256GB). After burning the adequate ISO firmware image, simply restart the PC to boot with the newly created CD/DVD boot disk (may work from a USB stick).<br />
<br />
The iso images just contain a linux kernel and an initrd. Extract them to {{ic|/boot}} partition and boot them with [[GRUB]] or [[Syslinux]] to update the firmware.<br />
<br />
I could not find a single page listing the firmware updates yet (site is a mess IMHO), but here are some relevant links:<br />
<br />
SanDisk Extreme SSD [http://kb.sandisk.com/app/answers/detail/a_id/10127 Firmware Release notes] and [http://kb.sandisk.com/app/answers/detail/a_id/10476 Manual Firmware update version R211] <br />
<br />
SanDisk Ultra SSD [http://kb.sandisk.com/app/answers/detail/a_id/10192 Firmware release notes] and [http://kb.sandisk.com/app/answers/detail/a_id/10477 Manual Firmware update version 365A13F0]<br />
<br />
== See also ==<br />
<br />
* [http://www.reddit.com/r/archlinux/comments/rkwjm/what_should_i_keep_in_mind_when_installing_on_ssd/ Discussion on Reddit about installing Arch on an SSD]<br />
* See the [[Flashcache]] article for advanced information on using solid-state with rotational drives for top performance.<br />
* [http://lifehacker.com/5837769/make-sure-your-partitions-are-correctly-aligned-for-optimal-solid-state-drive-performance Speed Up Your SSD By Correctly Aligning Your Partitions] (using GParted)<br />
* [http://permalink.gmane.org/gmane.comp.file-systems.btrfs/19446 Re: Varying Leafsize and Nodesize in Btrfs]<br />
* [http://thread.gmane.org/gmane.comp.file-systems.btrfs/19650/focus=19667 Re: SSD alignment and Btrfs sector size]<br />
* [http://forums.anandtech.com/showthread.php?t=2266113 Erase Block (Alignment) Misinformation?]<br />
* [http://superuser.com/questions/492084/is-alignment-to-erase-block-size-needed-for-modern-ssds Is alignment to erase block size needed for modern SSD's?]<br />
* [http://thread.gmane.org/gmane.comp.file-systems.btrfs/15646 Btrfs support for efficient SSD operation (data blocks alignment)]<br />
* [http://serverfault.com/questions/356534/ssd-erase-block-size-lvm-pv-on-raw-device-alignment SSD, Erase Block Size & LVM: PV on raw device, Alignment]</div>Kritztopfhttps://wiki.archlinux.org/index.php?title=Open-iSCSI&diff=326030Open-iSCSI2014-07-21T14:17:32Z<p>Kritztopf: /* Setup With Open-iSCSI */ open-iscsi is now available in [community]</p>
<hr />
<div>[[Category:Storage]]<br />
[[Category:Networking]]<br />
{{Related articles start}}<br />
{{Related|iSCSI Target}}<br />
{{Related|iSCSI Boot}}<br />
{{Related articles end}}<br />
<br />
With [[Wikipedia:iSCSI]] you can access storage over an IP-based network.<br />
<br />
The exported storage entity is the '''[[iSCSI Target|target]]''' and the importing entity is the '''initiator'''.<br />
<br />
The preferred initiator is [http://open-iscsi.org/ Open-iSCSI] as of 2011. An older initiator, [http://sourceforge.net/projects/linux-iscsi/ Linux-iSCSI], was merged with Open-iSCSI.<br />
Linux-iSCSI should not be confused with linux-iscsi.org, the website for the LIO [[iSCSI Target|target]].<br />
<br />
== Setup With Open-iSCSI ==<br />
{{Pkg|open-iscsi}} is available in the official repositories. Install it with {{bc|# pacman -S open-iscsi}}<br />
<br />
=== Using the Daemon ===<br />
You only have to include the IP of the [[iSCSI Target|target]] as {{ic|SERVER}} in {{ic|/etc/conf.d/open-iscsi}} at the client.<br />
<br />
At the server (target) you might need to include the client iqn from {{ic|/etc/iscsi/initiatorname.iscsi}} in the acl configuration.<br />
<br />
After both steps are finished you should be able to start the initiator with {{bc|# systemctl enable open-iscsi.service<br />
# systemctl start open-iscsi.service}}<br />
You can see the current sessions with {{bc|# systemctl status open-iscsi.service}}<br />
<br />
== Using the Tools ==<br />
{{ic|iscsid}} has to be running.<br />
<br />
=== Target discovery ===<br />
{{bc|# iscsiadm -m discovery -t sendtargets -p <portalip>}}<br />
=== Delete obsolete targets ===<br />
{{bc|# iscsiadm -m discovery -p <portalip> -o delete}}<br />
<br />
=== Login to available targets ===<br />
{{bc|# iscsiadm -m node -L all}}<br />
or login to specific target<br />
{{bc|<nowiki># iscsiadm -m node --targetname=<targetname> --login</nowiki>}}<br />
<br />
logout:<br />
{{bc|# iscsiadm -m node -U all}}<br />
<br />
=== Info ===<br />
For running session<br />
{{bc|# iscsiadm -m session -P 3}}<br />
The last line of the above command will show the name of the attached dev e.g<br />
{{bc|Attached scsi disk '''sdd''' State: running}}<br />
<br />
For the known nodes<br />
{{bc|# iscsiadm -m node}}<br />
<br />
=== Online resize of volumes ===<br />
If the iscsi blockdevice contains a partitiontable, you will not be able to do an online resize. In this case you have to unmount the filesystem and alter the size of the affected partition.<br />
# Rescan active nodes in current session {{bc|# iscsiadm -m node -R}}<br />
# If you use multipath, you also have to rescan multipath volume information. {{bc|# multipathd -k"resize map sdx"}}<br />
# Finally resize the filesystem. {{bc|# resize2fs /dev/sdx}}<br />
<br />
== Tips ==<br />
You can also check where the attached iSCSI devices are located in the /dev tree with {{ic|ls -lh /dev/disk/by-path/* | grep ip}}.<br />
<br />
== See also ==<br />
* [[iSCSI Boot]] Booting Arch Linux with / on an iSCSI target.</div>Kritztopfhttps://wiki.archlinux.org/index.php?title=Lemonbar&diff=322259Lemonbar2014-06-29T14:21:51Z<p>Kritztopf: Removed unneccessary config.h source and adapted the examples to the new formatting syntax of bar.</p>
<hr />
<div>[[Category:Eye candy]]<br />
[https://github.com/LemonBoy/bar b(ar) a(in't) r(ecursive)] is a lightweight bar based on XCB. It provides foreground/background color switching along with text alignment and colored under/overlining of text, full utf8 support and reduced memory footprint. Nothing less and nothing more.<br />
<br />
== Installation ==<br />
<br />
{{AUR|bar-aint-recursive}} is available in the AUR and can be installed manually or through the use of a AUR helper of your choice.<br />
<br />
== Configuration ==<br />
<br />
Configuration of bar is now completely done via {{ic|screenrc}}-like format strings and command line options as opposed to older versions, where configuration took place at compile-time.<br />
<br />
See the man page for a short overview of those configuration options.<br />
<br />
== Usage ==<br />
<br />
{{ic|bar}} prints no information on its own. To get any text into {{ic|bar}} you need to pipe text into it. The following example would write the text "Hello World" into your bar.<br />
<br />
{{bc|<br />
#!/bin/bash<br />
<br />
# Echo the text<br />
echo "Hello World"<br />
}}<br />
<br />
If you want the text in {{ic|bar}} to update through a script, you need to add the {{ic|-p}} option. This prevents {{ic|bar}} from exiting after stdin is closed.<br />
<br />
==== Colors ====<br />
<br />
{{ic|bar}} uses the following commands to color the text, background or the under/overline. Colors are to be specified via their symbolic names or in #AARRGGBB notation.<br />
<br />
{| border="1"<br />
! Command !! Meaning<br />
|-<br />
| {{ic|%{F#} }} || Uses the # color as the font's color<br />
|-<br />
| {{ic|%{B#} }} || Uses the # color as the background<br />
|-<br />
| {{ic|%{U#} }} || Uses the # color for under/overlining the text<br />
|}<br />
<br />
==== Text alignment ====<br />
<br />
{{ic|bar}} also supports alignment of text. It uses the following commands to align the text<br />
<br />
{| border="1"<br />
! Command !! Meaning<br />
|-<br />
| {{ic|%{l} }} || Aligns the text to the left<br />
|-<br />
| {{ic|%{c} }} || Aligns the text to the center<br />
|-<br />
| {{ic|%{r} }} || Aligns the text to the right<br />
|}<br />
<br />
==== Examples ====<br />
<br />
The following example prints the date and time in the middle of the bar, the font's color being {{ic|yellow}} and the background {{ic|blue}} and changes the font's color back to the default color afterwards. Run it with {{ic|/path/to/script/example.sh &#124; bar -p}}<br />
<br />
{{hc|example.sh|<br />
#!/usr/bin/bash<br />
<br />
# Define the clock<br />
Clock() {<br />
DATE&#61;$(date "+%a %b %d, %T")<br />
<br />
echo -n "$DATE"<br />
}<br />
<br />
# Print the clock<br />
<br />
while true; do<br />
echo "%{c}%{Fyellow}%{Bblue} $(Clock)%{F-}"<br />
sleep 1;<br />
done<br />
}}<br />
<br />
Another example showing the battery percentage. To use this script you need to install {{Pkg|acpi}}.<br />
<br />
{{hc|example.sh|<br />
#!/usr/bin/bash<br />
<br />
#Define the battery<br />
Battery() {<br />
BATPERC&#61;$(acpi --battery &#124; awk -F, '{print $2}')<br />
echo "$BATPERC"<br />
}<br />
<br />
# Print the percentage<br />
while true; do<br />
echo "%{r}$(Battery)"<br />
sleep 1;<br />
done<br />
}}</div>Kritztopfhttps://wiki.archlinux.org/index.php?title=Chrony&diff=203742Chrony2012-06-05T12:30:48Z<p>Kritztopf: /* Telling chronyd an internet connection has been made */</p>
<hr />
<div>[[Category:Networking]]<br />
[[Category:Daemons and system services]]<br />
{{i18n|Chrony}}<br />
<br />
This article describes how to set up and run Chrony, an alternative NTP client and server that is dial-up friendly and designed specifically for systems that are not online all the time.<br />
<br />
==Installation==<br />
{{Pkg|chrony}} is available from the [community] repository.<br />
<br />
==Configuration==<br />
The first thing you define in your {{ic|/etc/chrony.conf}} is the servers your machine will synchronize to.<br />
NTP servers are classified in a hierarchical system with many levels called ''strata'': the devices which are considered independent time sources are classified as ''stratum 0'' sources; the servers directly connected to ''stratum 0'' devices are classified as ''stratum 1'' sources; servers connected to ''stratum 1'' sources are then classified as ''stratum 2'' sources and so on.<br />
<br />
It has to be understood that a server's stratum cannot be taken as an indication of its accuracy or reliability. Typically, stratum 2 servers are used for general synchronization purposes: if you do not already know the servers you are going to connect to, you should use the [http://www.pool.ntp.org/ pool.ntp.org] servers ([http://support.ntp.org/bin/view/Servers/NTPPoolServers alternate link]) and choose the server pool that is closest to your location.<br />
<br />
The following lines are just an example:<br />
<br />
server 0.pool.ntp.org<br />
server 1.pool.ntp.org<br />
server 2.pool.ntp.org<br />
server 3.pool.ntp.org<br />
<br />
If your computer is not connected to the internet on startup, it is recommended to use the ''offline'' option, to tell chrony not to try and connect to the servers, until it has been given the go:<br />
<br />
server 0.pool.ntp.org offline<br />
server 1.pool.ntp.org offline<br />
server 2.pool.ntp.org offline<br />
server 3.pool.ntp.org offline<br />
<br />
It may also be a good idea to either use IP addresses instead of host names, or to map the hostnames to IP addresses in your {{ic|/etc/hosts}} file, as DNS resolving won't be available until you've made a connection.<br />
<br />
To tell chronyd that a connection has been established, you need to be able to log in with chronyc. You will have to configure chronyd with an administrator password to be able to do this. Setting up an administrator password is as simple as creating the file {{ic|/etc/chrony.keys}} with a single line:<br />
<br />
{{hc|/etc/chrony.keys|1 xyzzy}}<br />
<br />
as well as adding the following line somewhere in {{ic|/etc/chrony.conf}}:<br />
<br />
commandkey 1<br />
<br />
The smallest useful configuration file (using IP addresses instead of a hostname) would look something like: <br />
<br />
{{hc|/etc/chrony.conf|<br />
server 1.2.3.4 offline<br />
server 5.6.7.8 offline<br />
server 9.10.11.12 offline<br />
keyfile /etc/chrony.keys<br />
commandkey 1<br />
driftfile /etc/chrony.drift<br />
}}<br />
<br />
===Telling chronyd an internet connection has been made===<br />
For this to work, you'll need to configure the {{ic|commandkey}} option in {{ic|/etc/chrony.conf}} as shown above. If you've done this, start {{ic|chronyc}} and enter the following commands if you are connected to the internet:<br />
{{bc|<br />
chronyc> password xyzzy<br />
200 OK<br />
chronyc> online<br />
200 OK<br />
chronyc> exit<br />
}}<br />
<br />
Chrony should now connect to the configured time servers and update your clock if needed.<br />
<br />
To tell chrony that you are not connected to the internet anymore, execute the following:<br />
{{bc|<br />
chronyc> password xyzzy<br />
200 OK<br />
chronyc> offline<br />
200 OK<br />
chronyc> exit<br />
}}<br />
<br />
In conclusion, don't forget the user guide at {{ic|/usr/share/doc/chrony/chrony.txt}}, which is likely to answer any doubts you could still have. [http://chrony.tuxfamily.org/manual.html It is also available online.] See also the related man pages: {{ic|man <nowiki>{chrony|chronyc|chronyd|chrony.conf}</nowiki>}}).<br />
<br />
==Usage==<br />
===Starting chronyd===<br />
chronyd runs as a daemon in the background, keeping track of the clock, and waiting for it to be told to go online and synchronize the time with the servers.<br />
<br />
Stop the hwclock daemon (if it is running):<br />
<br />
{{bc|# rc.d stop hwclock}}<br />
<br />
Start the chrony daemon:<br />
{{bc|# rc.d start chrony}}<br />
<br />
Add chrony to your DAEMONS array so it starts automatically on boot and make sure hwclock is disabled:<br />
{{hc|/etc/rc.conf|2=DAEMONS=(... !hwclock '''chrony''' ...)}}<br />
<br />
===Using NetworkManager to let chronyd go online===<br />
''chronyd'' can be go into online/offline mode along with a network connection through the use of [[NetworkManager#Network Services with NetworkManager Dispatcher|NetworkManager's dispatcher scripts]]. You can install {{AUR|networkmanager-dispatcher-chrony}} from the AUR.<br />
<br />
==Alternatives==<br />
Alternatives to the Chrony, are [[NTPd]], the standard NTP client/daemon for Linux, and [[OpenNTPD]], part of the OpenBSD project and currently not maintained for Linux.<br />
<br />
==See also==<br />
* [[Time]] (for more information on computer timekeeping)<br />
<br />
==External links==<br />
* http://chrony.tuxfamily.org/<br />
* http://www.ntp.org/<br />
* http://support.ntp.org/<br />
* http://www.pool.ntp.org/<br />
* http://www.eecis.udel.edu/~mills/ntp/html/index.html<br />
* http://www.akadia.com/services/ntp_synchronize.html</div>Kritztopf