You are not logged in.
Pages: 1
First post! Hi Arch
I'm going to get rid of the x4 old hand me down Linux boxes and x2 old Dells when I move into my home next month. I'm going to just TRIM down my home network significantly to just a MacBook Pro & a new 2015 i7 custom build w/ 32 GB of RAM. I'm questioning SSD's for the boot / OS partitions. I have a few questions if you guys don't mind in consideration to me reading this:
1. This will be my main system and being a typical Arch user, I want everything perfect. Should I worry about configuring my SSD's from day 1 or would it hardly make a difference and I wouldn't notice much performance loss over time as just as average home user?
As of Linux kernel version 3.8 onwards, the following filesystems support TRIM: Ext4, Btrfs, JFS, VFAT, XFS, F2FS.
2. I plan to use Arch only which clearly is on kernel release 4.x & all my drives will use XFS except boot which would use obviously Ext2.
Does this mean the only thing I need to do to enable TRIM is add 'discard' into my fstab file? If so, do I do this for every line on every partition? Swap? /boot?
3. Is there an other way to verify TRIM is enabled? I'd like to avoid installing random packages on my system if I can help it:
hdparm -I /dev/sda | grep TRIM
Thank you!
Offline
... except boot which would use obviously Ext2.
Why ext2? I certainly don't know why that'd be obvious.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
https://bbs.archlinux.org/viewtopic.php?id=155030
Reading this, it would seem that TRIM doesn't work on Ext2.
Last edited by old_computer (2015-06-06 04:07:44)
Offline
Does this mean the only thing I need to do to enable TRIM is add 'discard' into my fstab file? If so, do I do this for every line on every partition? Swap? /boot?
I suspect you would have to enable TRIM on all partitions on ssd. Not sure if that applies to the swap partition though.
Offline
I recommend using an fstrim systemd .timer to apply TRIM periodically rather than using the "discard" option in fstab as the latter will slow down your drive(s).
https://wiki.archlinux.org/index.php/So … md_service
The thread you have linked in post #3 is nearly three years old and no decisive argument is made in favour of ext2 as a filesystem for /boot
EDIT: Also, your new PC will have a UEFI motherboard and if you wish to take advantage of this you will have to format /boot to the FAT(32) filesystem as this is the only type your motherboard can read.
https://www.happyassassin.net/2014/01/2 … work-then/
Last edited by Head_on_a_Stick (2015-06-06 10:06:19)
Offline
1. This will be my main system and being a typical Arch user, I want everything perfect. Should I worry about configuring my SSD's from day 1 or would it hardly make a difference and I wouldn't notice much performance loss over time as just as average home user?
Personally, I don't think you're going to see that much of a difference (as a user) in tuning your SSD. Every now and again, I'll run across an article about tuning. I'll run the checks shown in the article and find that just formatting my drive had already set up my ssd optimally. But it never hurts to go about it properly. Especially if you want the perfect system.
2. I plan to use Arch only which clearly is on kernel release 4.x & all my drives will use XFS except boot which would use obviously Ext2.
Does this mean the only thing I need to do to enable TRIM is add 'discard' into my fstab file? If so, do I do this for every line on every partition? Swap? /boot?
The "obvious" choice on a brand new system would be fat32/ef00. But then, I haven't set up a linux system on a non-UEFI system in a couple of years. But yes, adding the discard option to your fstab is one way to go about it. I have my system set up to trim once a day via systemctl, but mine might be overkill.
3. Is there an other way to verify TRIM is enabled? I'd like to avoid installing random packages on my system if I can help it:
hdparm -I /dev/sda | grep TRIM
If the ssd(s) are new, then you probably have bought drives that support trim. The above command just lets you know if the drive supports trim. If you don't want to install anything else, you can probably just run fstrim on each drive, then check your journal.
Offline
Huh? Is this link supposed to be an answer to my question? You say using ext2 for boot is the "obvious" choice almost as if that is required. I ask why you think this, and you link to a thread where someone asked if they should use ext2 for boot and got a range on answers around "it doesn't matter" to people saying what their boot partition was, none of which were ext2.
There is *no* reason I am aware of, and certainly none presented in that thread, to favor ext2 for a boot partition. There are reasons here why you should *not* use ext2.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
I use ext2 for /boot. I don't use EFI (in which case you'd use FAT32), and I don't want to rely on GRUB's support for more complicated filesystems/situations such as RAID/LUKS/LVM (if you trust GRUB to handle those you don't need a /boot partition at all). ext2 /boot may be old fashioned but it keeps things simple for me.
it would seem that TRIM doesn't work on Ext2.
It works fine (if using ext4 driver to mount ext23 as is the case in recent kernels).
# mkfs.ext2 /dev/SSD/foobar
# mount -t ext2 /dev/SSD/foobar /mnt/foobar
[ 7522.922738] EXT4-fs (dm-37): mounting ext2 file system using the ext4 subsystem
[ 7522.928817] EXT4-fs (dm-37): mounted filesystem without journal. Opts: (null)
# fstrim -v /mnt/foobar
/mnt/foobar: 244.3 MiB (256196608 bytes) trimmed
Last edited by frostschutz (2015-06-06 11:10:20)
Offline
Thanks for the feedback. I wasn't aware of new systems using EFI so I guess there's no reason to run /boot on anything other than a FAT 32 partition. Would the following be logical to use:
/dev/sda1 = swap 4 GB (SWAP)
/dev/sda2 = /boot (FAT 32)
/dev/sda3 = / (XFS)
/dev/sdb1 = /home (XFS)
/dev/sdb2 = /var (XFS)
In doing more research based on feedback in this thread, I think using fstrim periodically in systemd is likely 'good enough' solution for me.
Offline
Thanks for the feedback. I wasn't aware of new systems using EFI so I guess there's no reason to run /boot on anything other than a FAT 32 partition.
Ignore all that. This thread got derailed ridiculously quickly. Your original question was whether the discard flag would suffice to turn on TRIM, and the answer is yes. You'd need to enable it for each partition, but that would do it. However, as head_on_a_stick suggested, I personally use (and recommend) using fstrim maybe once every week or so to clear old blocks. You can either run it manually or schedule it to run periodically.
Now, if you have any concerns about booting Arch from your new Macbook (which will definitely be using UEFI to boot) you can read the relevant pages on UEFI in the Arch wiki, and start a new thread if anything's lost on you.
Offline
Ignore all that. This thread got derailed ridiculously quickly.
Yeah. My oblivious mistake was using the word 'obviously' which then highlighted another confusion that I don't know how to properly format a basic Arch system on a new EFI motherboard. I'm guessing it also rolled some eyes too...
Your original question was whether the discard flag would suffice to turn on TRIM, and the answer is yes. You'd need to enable it for each partition, but that would do it. However, as head_on_a_stick suggested, I personally use (and recommend) using fstrim maybe once every week or so to clear old blocks. You can either run it manually or schedule it to run periodically.
Perfect. I'm going to use this suggestion as it seems to be what everyone is doing and recommends. What's good for the goose...
Now, if you have any concerns about booting Arch from your new Macbook (which will definitely be using UEFI to boot) you can read the relevant pages on UEFI in the Arch wiki, and start a new thread if anything's lost on you.
No, I actually enjoy OS X as well. I really just love running Arch on any customer PC or VM possible. Thanks again for the helpful info!
Offline
If you have 32gig of ram... do you really need a swap partition? It will just gather dust?
Offline
Do we technically need Swap anymore in general? Are you hitting Swap w/ 4? 8? 16? I mean at what level do we not do a Swap partition and I think this is a totally separate topic but some apps in Linux depend and require Swap space regardless of system RAM.
Offline
I think this is a totally separate topic but some apps in Linux depend and require Swap space regardless of system RAM.
Can you give an example of an app that needs swap regardless of system memory? I am curious, because I don't know of any.
Offline
old_computer wrote:I think this is a totally separate topic but some apps in Linux depend and require Swap space regardless of system RAM.
Can you give an example of an app that needs swap regardless of system memory? I am curious, because I don't know of any.
You need to have swap space in order to hibernate. [1] This does not have to be a separate swap partition though. I can imagine setups that just create a swapfile on the fly.
Offline
Do we technically need Swap anymore in general? Are you hitting Swap w/ 4? 8? 16? I mean at what level do we not do a Swap partition and I think this is a totally separate topic but some apps in Linux depend and require Swap space regardless of system RAM.
On my recent Arch install on laptop with 4gig ram, I hadn't set up swap correctly. Opening several google-chrome tabs and a few other heavyish programs (neo4j, Pycharm ..) I fairly quickly ran out of ram. My system used to just freeze when it got nearly out of memory. When I realized my swap wasn't configured correctly and fixed that, the problem was gone.
Even the though the typical swap usage is <300 mb on my system, it is in a way indispensable to have.
Offline
Pages: 1