[SOLVED] Is this /etc/fstab right for SSD

[TabletHater]

During the installation (of Mageia Beta) I've used noatime option and ticked "clean /tmp at each boot" and my /etc/fstap says no:

UUID=ab91767d-e504-416f-a012-7dcb039410f2 / ext4 acl,relatime 1 1
/dev/cdrom /media/cdrom auto umask=0,users,iocharset=utf8,noauto,ro,exec 0 0
none /proc proc defaults 0 0
none /tmp tmpfs defaults 0 0

Is this correct? Asking this because in buntu distros I used to follow different instructions and edit fstap so as to read at the end of the UUID line:

..... ext4 errors=remount-ro,noatime,discard 0 1

and add these lines:

none /tmp tmpfs nodev,nosuid,mode=1777 0 0
none /var/tmp tmpfs nodev,nosuid,mode=1777 0 0

[djennings]

relatime is fine for use on SSDs It means the access time is only updated on writing.

However if the Mageia 2 Beta installer did not respect your selection of noatime on install then it is a bug that should be reported.
Does it work if you change the option using Mageia Control Centre>LocalDiscs>ManageDiscPartitions ?

[TabletHater]

Thanks, djennings. I'll report the bug, but I'm afraid of playing with partitions.

[djennings]

Hold fire on reporting the bug a few minutes. I am just testing it out myself.
I am just doing the install. I did not notice where it said to clean /tmp on boot. I must have missed it.

[TabletHater]

I can't remember either, but in bootloader step I guess --a bit dip down.

[djennings]

Yes, You are correct
My install just finished and my partition is mounted with acl, and relatime options in defiance of my selection of noatime and no acl.

I can change it to noatime easily enough after install with MageiaControlCentre, but the installer should be respecting the option.

Let us know the bug number when it is created.

BTW: I do not think there is anything wrong with the definition of /tmp

[TabletHater]

Bug 4736.
https://bugs.mageia.org/post_bug.cgi

[doktor5000]

Bug 4736.
https://bugs.mageia.org/post_bug.cgi

That would be https://bugs.mageia.org/show_bug.cgi?id=4736

[TabletHater]

Thank you Doktor!

[louielouie]

Don't forget the trim option for SSD's by using 'discard' in the options list.

[TabletHater]

Thanks louielouie.

[doktor5000]

Don't forget the trim option for SSD's by using 'discard' in the options list.

Do you have any reference information that is really a good thing to use? F.ex. quoting from Archlinux Wiki:

Mount Flags

There are several key mount flags to use in one's /etc/fstab entries for SSD partitions.

[...]
discard - The discard flag will enable the benefits of the TRIM command so long as one is using kernel version >=2.6.33. It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.
[...]
The factual accuracy of this article or section is disputed.
Please help improve the article and verify/correct/remove disputed content. (Discuss)

Warning: It is critically important that users switch the controller driving the SSD to AHCI mode (not IDE mode) to ensure that the kernel is able to use the TRIM command.
Warning: Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the discard flag. Data loss can occur otherwise!
Warning: Using an OCZ Vertex II SSD (supports TRIM) and kernel 2.6.37.4 on Arch, some people experienced trouble with the discard option: all changes made to the filesystem would disappear after a reboot! According to this ( http://www.mjmwired.net/kernel/Document ... t4.txt#356) discard is disabled by default because it not stable enough.
Note: For an alternative to the discard flag, see this discussion http://opensuse.14.n6.nabble.com/SSD-de ... 13048.html

[TabletHater]

I know that my SSD supports TRIM and have used this option in buntus, but since it's a controversial subject I'll disable it now. Thanks Doktor.

[TabletHater]

Any comment on this?

http://apcmag.com/how-to-maximise-ssd-p ... -linux.htm

[doktor5000]

Well, i won't myself use discard mount option, and also not change scheduler. It sounds good, but you should be really knowing what you change there.
Read up from different sources on this topic, then do your own benchmarks, then take a decision. I won't switch to noop scheduler, IMHO it's not worth it. there's no measurable change.

The stuff about swap and /tmp doesn't necessarily only apply to SSDs. For me, i don't need swap at all, as i don't use hibernation/suspend,
but using tmpfs, which can easily be enabled in MCC - bootloader setup -> advanced options.

[TabletHater]

I don't use swap either, but after the last couple of updates system can't go to sleep automatically.

Another thing I want to ask: How to set up Konqueror and Rekonq for SSD?

[dubigrasu]

BIG RED (AND BLUE) DISCLAIMER

Some of the info contained in the following post is debatable, feel free to use it or discard it (pun intended ), check its validity from external sources and do your own tests and benchmarks to decide according to your own judgement whether to use it or not.
Be aware that the discard method is still considered risky to use and depending on the SSD drive probably unnecessary. Personally I never had any problem in aprox 1 year since I use it but that is no real guarantee.
In the end, the point of this post is to talk about PARTITION ALIGNMENT.

Also, the test described below is merely a method to check whether TRIM/Garbage collection is working or not as described (purging the data). Succeeding the test is NOT a demonstration in itself that your SSD lifespan is gonna be increased, this is NOT its purpose.

References: https://wiki.archlinux.org/index.php/Solid_State_Drives https://wiki.archlinux.org/index.php/SSD_Benchmarking


END OF THE BIG RED (AND BLUE) DISCLAIMER
.......................................................................................................................................................................................

Enabling Trim is essential for prolonging SSD´s lifespan. However, you must check if is properly working. You can use this method (second page):
http://techgage.com/article/enabling_an ... er_linux/1

Be aware though that in order to work correctly you´ll need to have the drive properly aligned first, something that it isn't usually done at install time. I heard that Ubuntu does that but Mageia didn't. So just enabling Trim in fstab won´t cut it.
There are two methods to do it, GPT and MBR:
https://wiki.archlinux.org/index.php/So ... _Alignment

My initial TRIM tests on the old regular Mageia installation were negative, only after partition alignment and a second installation (*note) I could see TRIM indeed working.

Code: Select all

[root@localhost ~]# seq 1 1000 > testfile
[root@localhost ~]# hdparm --fibmap testfile

testfile:
 filesystem blocksize 4096, begins at LBA 2048; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0   11159520   11159527          8
[root@localhost ~]# sync
[root@localhost ~]# hdparm --read-sector 11159520 /dev/sda

/dev/sda:
reading sector 11159520: succeeded
0a31 0a32 0a33 0a34 0a35 0a36 0a37 0a38
0a39 3031 310a 0a31 3231 310a 0a33 3431
310a 0a35 3631 310a 0a37 3831 310a 0a39
3032 320a 0a31 3232 320a 0a33 3432 320a
....................................................
[root@localhost ~]# rm testfile
rm: remove regular file `testfile'? y
[root@localhost ~]# sync
[root@localhost ~]# hdparm --read-sector 11159520 /dev/sda

/dev/sda:
reading sector 11159520: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
....................................................
[root@localhost ~]#



(*note) Actually, I copied my installation to another drive and copied back to the SSD drive after partition alignment. I really didn't want to reinstall the whole thing again.

[TabletHater]

Thanks dubigrasu. I get this far:

Code: Select all

[burak@localhost ~]$ su
Password:
[root@localhost burak]# seq 1 1000 > testfile
[root@localhost burak]# hdparm --fibmap testfile

testfile:
 filesystem blocksize 4096, begins at LBA 2048; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0       -          -          -   
[root@localhost burak]#

[dubigrasu]

Yes, sometimes you need to repeat the command ( hdparm --fibmap testfile) until you have a result.

[TabletHater]

Thanks a lot dubigrasu. I've got those all 0s!

[dubigrasu]

[TabletHater]

Just one last thing: I know how to configure Firefox and Opera for SSD, but don't know how to configure Konqueror and Rekonq for SSD? Can you help?

[dubigrasu]

I have no idea
I don´t know any specific tweaks for them.

[TabletHater]

All right. Thanks.

[doktor5000]

Enabling Trim is essential for prolonging SSD´s lifespan. However, you must check if is properly working. You can use this method (second page):
http://techgage.com/article/enabling_an ... er_linux/1

Actually, do you have any credible reference information which supports that opinion?
You know, most SSDs those days do internal garbage collection and trimming, so mostly this is not really needed.

My citation of the comments that comes with ext4 source code still stands true, which says that
discard is still not really tested and stable and that's why it's disabled by default. And mostly
the kernel stuff has pretty sane and conservative defaults, you should think about that ...

So, being a bit heretical, where does this test show, that it will definitely prolong the lifespan of your SSD?
That's purely interpretation ...