You are not logged in.
I haven't tried the steps on here yet, but I thought I'd mention that for no. 2, I updated my fstab to
discard
not
noatime
Also, I screwed up the first step; when installing Waldorf, I created about 2GB of swap; is there a way to remove that and open it back up the the rest of the drive?
But I'm fuzzy on the difference between them.
Fortune favors the bold.
#! WALDORF (just converted)
Asus EEEPC 1001PXD
2GB RAM
Offline
Also, I screwed up the first step; when installing Waldorf, I created about 2GB of swap; is there a way to remove that and open it back up the the rest of the drive?
But I'm fuzzy on the difference between them.
You can remove the swap from your fstab and delete the partition. Then enlarge one of the others into that space.
You'll have to turn the swap off before you can delete it.
swapoffshould do the trick.
Last edited by AlanD (2012-10-24 12:20:08)
Offline
I haven't tried the steps on here yet, but I thought I'd mention that for no. 2, I updated my fstab to
discard
not
noatime
Also, I screwed up the first step; when installing Waldorf, I created about 2GB of swap; is there a way to remove that and open it back up the the rest of the drive?
But I'm fuzzy on the difference between them.
discard and noatime serve two completely different purposes. Discard causes your filesystem to write zeros over deleted data instead of just flagging them as being deleted, which improves the lifespan and performance of your drive. noatime causes your filesystem to not write to the drive every time a file is accessed, which reduces a lot of unnecessary writes and probably increases the lifespan of your drive, and may marginally improve performance to an unnoticeable extent. For a happy medium, you can use relatime, which causes the access time to be updated if they are earlier than the modification time. Really, unless you're worried about security issues caused by someone potentially viewing files on your machine without actually making changes to them, there's no reason to use the default of atime on a SSD. There's a far more in-depth explanation of this topic here: http://linux.koolsolutions.com/2009/01/ … t-options/
On a side note, a lot of the information in this howto isn't entirely relevant or up to date anymore, and when wheezy goes stable I will probably re-write it.
Last edited by mynis01 (2012-10-24 16:23:10)
Offline
On a side note, a lot of the information in this howto isn't entirely relevant or up to date anymore, and when wheezy goes stable I will probably re-write it.
I'd like to see some links (at least) to first hand experience with running LVM on SSDs. I know that since the 2.6.39 kernel LVM can do discard, but I'm not quite sure about block alignment, and you have mastered that.
Offline
mynis01 wrote:On a side note, a lot of the information in this howto isn't entirely relevant or up to date anymore, and when wheezy goes stable I will probably re-write it.
I'd like to see some links (at least) to first hand experience with running LVM on SSDs. I know that since the 2.6.39 kernel LVM can do discard, but I'm not quite sure about block alignment, and you have mastered that.
It's funny that you mention that because I was trying to set up LVM with drive encryption when I wrote this guide, but I was told that there's a 192 bit header at the beginning of LVM volumes that makes the alignment wacky. I'll have to google around at some point and figure out what exactly to do about it, maybe I'll make a post on stack exchange or something. In theory, all we should have to do is offset the beginning and end of the logical volumes....right? I was also going to throw in a little tidbit that shows how to make .vdi virtual disks for virtualbox align correctly (it's way more complicated than you would think).
Offline
There's an option to pass to pvcreate, but I forget what it is, not having an SSD myself. Google has the answers, I do know that one.
Offline
https://wiki.archlinux.org/index.php/LV … al_volumes
According to the Arch wiki, this should be enough. There's a follow up link, Yours?
Offline
Not mine, but I read the follow up link and I am still sorta confused. Basically what I'm reading is, if you align the LVM container correctly, then the actual partitions inside it don't really need to be aligned (or that them being offset inside a properly aligned container won't impact performance very much)?
Offline
That is my understanding as well. The firmware should work with the PV, not the LVs. But don't hold me to it.
Offline
I take that the update at the bottom of the first post (10-24-2012) reflects some of the insight from the past posts and reflects a somewhat current procedure for crunchbang?
Also, will moving all of these processes into RAM cause some sort of slowdown on consrticted systsm (<=1Gb)?
Offline
I'm not really sure if the browser mods still work or not with more recent iterations of the various browsers, but I'm assuming they will if you're using iceweasel/chromium from the stable repos. If you have <=1Gb RAM, I'd probably just leave the temp files and various things on the disk instead of in memory. Like I said before, I'm not really maintaining this page anymore since debian wheezy will likely be out soon, so YMMV.
Last edited by mynis01 (2012-10-31 16:22:57)
Offline
Hi Folks,
I'm about to set up my newly built PC and will need to configure my SSD for a fresh install of #!.
I know this thread isn't really being maintained anymore but I thought it would be worth checking if there's anything in the original post that you would consider irrelevant now or that would be done differently - I realise this seems to be a rapidly changing area.
I read that you should set up a single / partition across the whole drive, is there any reason I can't split the SSD into two partitions for dual boot? Each of these would be a / partition, data on the HDD along with an 8GB swap partition (I realise this is probably overkill and not really necessary but with 2TB on the HDD I don't see any harm in it).
This will be installing #! 64-bit Stable + Backports
Core i5-3570K
8GB RAM
120GB OCZ Vertex 4 SSD
2TB Seagate Barracuda HDD
Any links or pointers would be appreciated.
Assuming it doesn't blow up! My first build and I'm just about to plug it in for the first time - wish me luck...
Offline
That is fairly recent HW, so I would go for Waldorf. It is real stable now.
bootinfoscript - emacs primer - I ♥ #!
Online
As long as you set up GPT all your partitions will be aligned for you automatically. Then just make sure you add the discard option to all your partitions in /etc/fstab to enable TRIM and you will be good to go. The other stuff in the guide is just minor tweaks.
Offline
Excellent, thanks!
Offline
Hi there!
I installed #! 10 (Statler) on a 4GB USB thumbdrive (using the graphical installer and utilizing it like a real HDD). The fact why I did no persistant live installation was, that I read there are several actions that can't be done (e. g. kernel updates) when using a persistant live environment.
Now I have some questions and would be pleased to have them answered.
1) Can (even should!?) some/all of the before mentioned changes also be done to lengthen the lifespan of the USB stick?
2) If 1 is "yes", which changes should be done (moving parts to tmpfs / changing the scheduler / ...)?
3) Should it be fine to leave out the SWAP partition (having 1GB of system RAM)?
4) Which scenario would be the best solution (if applicable after all)
4.1) Having every partition (/, /var, /tmp, /home, ...) as a separate logical partition and trying to mount it to tmpfs in /etc/fstab - or -
4.2) Having a simple setup (like just having /home as a separate logical partition) and trying to mount only certain folders to a tmpfs?
I already played around a bit with several settings and the system works quite fine but before doing halfhearted things I rather try to give it the best shot possible so thank you for your assistance in advance.
Best regards!
Offline
Since you said you only have 1gb of RAM, I would maybe mount /tmp in tmpfs but nothing else, and keep your swap partition. I definitely would recommend setting noatime in /etc/fstab, that's a no brainer.
Offline
I found this howto regarding striping a LVM volume across some SSDs the other day. This would probably get you raid 0 type performance with TRIM support and the like. Unfortunately I don't really have the hardware available that I would need to test this, but it's here if you want to check it out: http://www.ocztechnologyforum.com/forum … t-on-Linux
Last edited by mynis01 (2012-12-27 22:22:31)
Offline
Hello all,
I did some digging after trying out the test in the first post. I did not have zero'ed data after following the guide. It turns out many newer ssd devices uses Deterministic TRIM; all read commands to the LBA after a TRIM shall return the same data, or become determinate. This guide works if your ssd uses Deterministic Read Zero after TRIM: all read commands to the LBA after a TRIM shall return zero.
Source; http://en.wikipedia.org/wiki/TRIM
Am I right in this asumption? We cannot test if discard actually works if our sdd uses Deterministic TRIM?
Offline
Copyright © 2012 CrunchBang Linux.
Proudly powered by Debian. Hosted by Linode.
Debian is a registered trademark of Software in the Public Interest, Inc.