maximbaz/dotfiles

Question: How uptodate is the btrfs section of your install guide?

stormsz opened this issue · 3 comments

stormsz commented

hey! great dotfiles!

  • i have been checking out your install "guide", and wondering how uptodate is the btrfs section?

i double checked it agaisnt the wiki and it seems fine, but i have very little experience with using btrfs.

  • Is there any good reason why you are using a subvolume for tmp logs and pkgs ?

  • any good reason to use continuous trim (mounting the subvolumes with the discard options) instead of using the systemd fstrim.timer?

  • you should probly update the pacstrap command to include a kernel since base wont be shipping one by default ( missing packages old base vs new base: http://0x0.st/zYn0.png )

maximbaz commented

hey and thanks 😄

i have been checking out your install "guide", and wondering how uptodate is the btrfs section?

It's not up to date at all, I wrote it when I installed Arch last time, which according to git history was in 2018 🙂

Is there any good reason why you are using a subvolume for tmp logs and pkgs ?

I use snapper to make btrfs snapshots of root subvolume and I didn't want these folders to be part of the snapshot, because they are easily recoverable.

any good reason to use continuous trim (mounting the subvolumes with the discard options) instead of using the systemd fstrim.timer?

The honest answer is "I don't know", any good reason to use fstrim.timer? Is it going to be performing better? Any drawbacks? I'm interested to get to the bottom of this! 🙂

you should probly update the pacstrap command to include a kernel since base wont be shipping one by default

Very true...

Thanks for bringing all these things up!

stormsz commented

well, according to my googling,
continuous trim uses trim commands every time a file is deleted, while the systemd option is just a timer that will run the trim commands once a week. The performance seems to be the same as in:
you will lose a bit of performance every time you delete a file if you are using continuous trim, or you will lose a "big" chunk of performance if you are using the systemd timer since theres more stuff to trim in one go. i have been using the timer for years and never actually noticed any serious performance hits when the trim starts.

also the arch wiki states that:

Warning: Before SATA 3.1 all TRIM commands were non-queued, so continuous trimming would produce frequent system freezes. In this case, applying #Periodic TRIM less often is better alternative. Similar issue holds also for a number of devices, for which queued TRIM command execution was blacklisted due to serious data corruption. In such case, depending on the device, the system may be forced to send non-queued TRIM commands the SSD instead of queued TRIM. See Wikipedia:Trim_(computing)#Disadvantages for details.

Note: Continuous TRIM is not the most preferred way to issue TRIM commands among the Linux community. For example, Ubuntu enables periodic TRIM by default [5], Debian does not recommend using continuous TRIM [6] and Red Hat recommends using periodic TRIM over using continuous TRIM if feasible. [7]

so as far i can tell they dont recommend continuous trim because some SSD's have bugs and it will end up with the trim command deleting critical data.

debian provides a pretty good explanation: https://wiki.debian.org/SSDOptimization#WARNING

tl.dr: if its working fine for you then i see no reason to change it and granted that the "install guide" is outdated one should not be using it but instead check it to get an idea of your setup.

anyway, thanks for the quick reply and explanation!

maximbaz commented

I see, interesting! I think it's worth trying out the periodic TRIM then 🙂

I do want to keep the install guide reasonably working, but you are right it's more for reference purposes, the main guide should of course be ArchWiki as it is kept up-to-date by many people at all times.

Nevertheless I pushed some updates according to your recommendations, thank you very much 😉