EXT4 on SSD

[KKJensen]

Hi there,

I've got a 8GB SSD in a netbook and followed the installation located at:

http://hwarf.com/2009/01/26/aspire-one-fedora-10/

SSD Optimization
Perform the following if you’re using an SSD. If you’re using a hard drive you can skip this section.
Create Ramdisks to Store Frequently Written Areas

1. Edit your /etc/fstab file. Add the following lines.
tmpfs /var/log tmpfs defaults 0 0
tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/tmp tmpfs defaults 0 0

Disable Access Time Attributes

1. Edit your /etc/fstab. Modify the root partitions settings. Add noatime and nodiratime to defaults.
/dev/sda2 / ext4 defaults,noatime,nodiratime 0 0

Optimizing the Kernel

1. Add the following to your /etc/rc.local file.
# Economize the SSD
sysctl -w vm.swappiness=1 # Strongly discourage swapping
sysctl -w vm.vfs_cache_pressure=50 # Don't shrink the inode cache aggressively

# As in the rc.last.ctrl of Linpus
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo ondemand > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
cat /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate_max > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate

echo 1500 > /proc/sys/vm/dirty_writeback_centisecs
echo 20 > /proc/sys/vm/dirty_ratio
echo 10 > /proc/sys/vm/dirty_background_ratio

echo 1 > /sys/devices/system/cpu/sched_smt_power_savings
echo 10 > /sys/module/snd_hda_intel/parameters/power_save
echo 5 > /proc/sys/vm/laptop_mode

#Decrease power usage of USB while idle
[ -w /sys/bus/usb/devices/1-5/power/level ] && echo auto > /sys/bus/usb/devices/1-5/power/level
[ -w /sys/bus/usb/devices/5-5/power/level ] && echo auto > /sys/bus/usb/devices/5-5/power/level

/sbin/setpci -d 197b:2381 AE=47
/sbin/modprobe pciehp
/sbin/modprobe sdhci

Change the I/O Scheduler

1. Edit the /etc/grub.conf file. Add “elevator=noop” to the kernel line.
kernel /vmlinuz-2.6.27.5-117.fc10.i686 ro root=/dev/sda

I see here though that EXT4 doesn't have any specific provisions for SSD drives

https://fcp.surfsite.org/modules/new...61077&start=10


QUESTION:
Should I be reinstalling with EXT2? Do these optimisations (The mods 'worked' but I'm not sure to what end.) really protect the ssd from excessive writing?

[RahulSundaram]

Hi,

You can use Ext4 without a journal which is more efficient than using ext2. Also read

http://thunk.org/tytso/blog/2009/02/...ized-for-ssds/

[Milena]

Hi,

You can use Ext4 without a journal

Hi

Will this command, used from a live-cd, disable ext4 journaling the right way ?

tune2fs -O ^has_journal /dev/sda1

assuming sda1 is my / partition.

Thanks

[RahulSundaram]

Hi,

Fedora Live CD is a preformatted Ext4 filesystem. I don't see how disabiling the journaling while running in live cd mode is actually useful but yeah that command should disable journaling for that session. It doesn't affect a installation to hard disk however.


Read my FAQ at

https://fedoraproject.org/wiki/Ext4_in_Fedora_11

[Milena]

Thanks Rahul

I was talking about disabling the ext4 journal for an already installed Fedora 12 on my SSD drive (/dev/sda1). The filesystem has to be umounted to use tune2fs on it, thats why i wanted to use a live-cd. The command gave no error messages so i guess it worked well, I restarted Fedora and the journal should be gone now.

that command should disable journaling for that session.

tune2fs -O ^has_journal /dev/sda1 has no persistent effect on the filesystem or did you just mean for a live-cd-fs ?

[marko]

I thought SSDs didn't have the excessive writing issue any more unlike CompactFlash and other more basic Flash memories because the firmware has wear leveling built in. The write statistics I've seen are so stringent that it would be very hard to work the drive so hard as to wear it out before you'd want to upgrade the disk anyway.

[Milena]

Yeah I think SSD wearing is more a myth, i'm just a desktop user and theres no excessive write access to the disc but i found benchmarks on phoronix saying ext4 without journal has increased performance and is recommend for SSDs together with the noop io scheduler. I got a samsung 64GB drive for 140€ recently, that should have a decent firmware for wear leveling.

[marko]

There is one thihg, his 8GB is so small that the drive doesn't have much room for wear leveling. That might make it more of a problem.

[bingoUV]

There is one thihg, his 8GB is so small that the drive doesn't have much room for wear leveling. That might make it more of a problem.

Most of the 8GB will be read-only. If the wear-levelling algorithm of the drive is any good, it should move around the data such that all parts of the SSD are uniformly written to.

[stevea]

tune2fs -O ^has_journal /dev/sda1 has no persistent effect on the filesystem or did you just mean for a live-cd-fs ?

Just wanna correct this.

Running:
tune2fs -O ^has_journal /dev/sdxxx
absolutely DOES have a persistent effect on the ext[234] file system. This can easily be observed using the
dumpe2fs -h /dev/sdxxx
command.

What exactly this impact is for ext4, I can't say without reviewing the kernel code, but it removes the "has_journal" feature persistently.

Some thoughts:
/When creating an ext4 fs using the "-O extent" option is probably a universally smart idea, but it's also the Fedora default.. See /etc/mke2fs.conf

/Just a personal opinion, but reserved blocks (the number of blocks reserved for root use if the FS gets full) defaults to 5% which was probably an OK choice when a disk was 100MB (then you had ~5MB for journals so you could see what was broken), but wneh ext[234] is by default setting aside 50GB of your 1TB drive for root something is horribly wrong. It should never have been a percentage.
tune2fs -r 1024 /dev/sdxxx
will set the reserve to 1K blocks = 4MB, which is minimalist.

/ext4 DOES have provision for SSD, and is the only FS that supported TRIM technology, if you mount with the "discard" option (currently undocumented I think).

/I am not a fan of eliminating journals without thinking through the consequences. An SSD has a limited lifespan, so you know the file system will fail in time. When it does without a journal you will lose files.. Personally I think removing the journal from the root file system seems rational. I can reconstruct a rootfs in ~1hr including all my customizations. I would hate to lose my personal work in /home or /opt - so those must have journals. Besides the rootfs has a load of writes (yum database, /var/log pid files) that I can afford to lose in a crash.

[Chilly Willy]

Yeah I think SSD wearing is more a myth, i'm just a desktop user and theres no excessive write access to the disc but i found benchmarks on phoronix saying ext4 without journal has increased performance and is recommend for SSDs together with the noop io scheduler. I got a samsung 64GB drive for 140€ recently, that should have a decent firmware for wear leveling.

I was checking out some made by Kingston & they claim 1,000,000 hour MTBF. So, if I did the math right, that is better that 100 yrs of continues usage. - Not likely to ware out any time soon that *I* can see. (if the claim is true) Shoot, if it last 10 yrs, I'd be well pleased. (I have some regular ones that are older)

[jpollard]

I was checking out some made by Kingston & they claim 1,000,000 hour MTBF. So, if I did the math right, that is better that 100 yrs of continues usage. - Not likely to ware out any time soon that *I* can see. (if the claim is true) Shoot, if it last 10 yrs, I'd be well pleased. (I have some regular ones that are older)

You better go back and check - that 1,000,000 hours is based
on FREQUENCY OF UPDATE under expected usage. Using it for
a root filesystem is not "expected usage". The wear and tear
is MUCH higher than a data only device.

[Chilly Willy]

You better go back and check - that 1,000,000 hours is based
on FREQUENCY OF UPDATE under expected usage. Using it for
a root filesystem is not "expected usage". The wear and tear
is MUCH higher than a data only device.

Even at that, if you cut this down, it's still quite a lot of hours of usage between failures, & also, I happened to say "if the claim is true". - the only MISTAKE I make was making MEANS TIME to close to CONTINUES but since the math come out to slightly over 114 yrs of MEANS TIME BETWEEN FAILURE, even a fraction of that would be considered a fair bet it WILL last on average a good number of yrs. - probably as long as the machine. - AGAIN, IF, IF, IF, there claim is valid.

BTW: I'm looking on newegg's site & it says MTBF - if you are seeing something else, then that is the problem.

[stevea]

+1 for JP.

You CANNOT ignore the limited number of writes to SSDs. This is a very real limitation limitation to SSDs drive, and I've no tolerance for denialists (doncha love the dismissive lefty lingo?). Intel has AFAIK, the best characterization available: They claim an 80GB & 160GB drives (with wear levelling) are good for 100 times the volume size writes before failure. This is write-wear, not statistical Raleigh stat failure - so MTTF is almost meaningless unless you spec the "writes per unit time".

http://www.intel.com/.../X18-M_and_X...s_Addendum.pdf

Check section 2.3, the 80GB drive has a write-endurance of 7.5TB written as 4K blocks. 15TB of writes for the 160TB drive. That's enough to last years, but whether it's 2.5 years or 10 years makes a big difference to most.

[jpollard]

Even at that, if you cut this down, it's still quite a lot of hours of usage between failures, & also, I happened to say "if the claim is true". - the only MISTAKE I make was making MEANS TIME to close to CONTINUES but since the math come out to slightly over 114 yrs of MEANS TIME BETWEEN FAILURE, even a fraction of that would be considered a fair bet it WILL last on average a good number of yrs. - probably as long as the machine. - AGAIN, IF, IF, IF, there claim is valid.

BTW: I'm looking on newegg's site & it says MTBF - if you are seeing something else, then that is the problem.

Nope - MTBF is valid. But you need to realize that to get that
figure they first run samples of the chips (random selections)
and run them to failure. In the lab that may take a few weeks
(or just a few days). Now they have a total number of writes
per time (whatever it was) until failure.

Now they divide the total number of writes until failure, by
the expected number of writes per unit of time. This gives
an expected time to failure. Now average that over all
the samples.

The actual calculation may average the time to fail first... but
either way you get a MTBF that will be quite impressive...

But it all reduces to the number of expected writes per unit of
time. If you exceed that amount, then your failure will occur
sooner.

If you exceed it a lot (as in using it for a root file system) then
your failure could occur in a year or two, or even a month
(though that is unlikely except in a lab with continuous writes
going on).

This is the same tests done on disks - and disks have a MTBF
of only 3 -4 years. The difference is the number of expected
operations performed per unit of time is different (a much
bigger number).

Oh - I believe the warranty is set based on the MTBF; 15%
or so less than the MTBF value, but if you exceed the write
rate and they find out, then I expect the warranty to be voided.