so it’s been a while since I last manually worked on my fstab (~8 years), so I’m very unsure if what I’m doing is correct, and I’m looking for someone to proofread, what I’m adding just so I do not involuntarily destroy my system.
I’ve just installed a 120GB SSD SATA III which will work as a shared disc between different distributions, with Manjaro being my main.
Not sure about the discard. The rest should be alright. UUID is correct, mountpoint will be made and /ssds will get these permissions: sudo chmod ug+rwx /ssds (as I’m the only one working on this PC I’m forgoing ugo)
Anything I must or should change anything I need to add/remove?
defaults is not needed unless there are no other options, but it won’t hurt. Perhaps consider relatime instead of noatime.
You can test it without rebooting:
sudo systemctl daemon-reload
sudo mount -a
They’re practically the default permissions anyway, you’d only be adding w for the group (which is probably pointless unless you have a group with other users who need to write to it).
If it’s only going to be used by your user, you should own the mountpoint:
That’s a though one. Tried to read about noatime yesterday and didn’t find anything that made me understand what the implications are
Any suggestions what to read? Going to look myself, but appreciate good tips
5 minutes later… it seems to be a matter of ‘faith’ which to choose. I’d guess noatime is used, because it’s been used more often or first and has just become a default that way. https://superuser.com/questions/1156868/is-relatime-better-than-noatime-on-fstab-for-ssd
Why remount all drives? To check for dependencies and to see if the fstab really works?
As my user is in the root user group, doesn’t the group also needs access?
As the drive will be used by the same user coming from different distribution on different drives, I’m very unsure if this is a good idea.
According to the first thread in m starting post, this is not a good idea:
The /data folder
To help yourself locating your folders easily you should use a consistent approach across your systems. When you share partitions across users it is preferable to use a location outside the /home structure and thus avoiding permissions issues across users.
The /media folder
Systemd uses a media folder located under /run to mount removable medias on the fly. The root folder /media is a folder commonly used for mounting removable media on a defined structure. Ubuntu and other distros uses this and certain auto-mount utilities utilize the /media folder.
… and I might have found my error:
When you share partitions across users it is preferable to use a location outside the /home structure and thus avoiding permissions issues across users.
But I’m not sharing it across different users, am I? I’m using the same user on different drives and distributions, correct? So I could mount it in my home folder?
Some (few) programs rely on file access times for their correct function.
I seem to recall as one example mutt (a mail client).
With noatime there is less write access which reduces wear and presumably makes things a bit faster.
relatime is the default
from man mount:
Access time is only updated if the previous access time was earlier than the current modify or change time. (Similar to noatime,
but it doesn’t break mutt(1) or other applications that need to know if a file has been read since the last time it was modified.)
The question is: how to identify those?
For now I’ll “outsource” the profiles of Firefox and Thunderbird and a local folder for (larger) files I do not want to store and work on on the NAS before they are finished or not used anymore.
I don’t know (beyond mutt, the one that is even mentioned in the manual page as an example).
Databases, probably.
I use the default (relatime).
If you set it to noatime and almost inevitably forget about it after some time
and then install some program (like mutt)
it can take quite a while to find out why it isn’t working as expected
even though it’s not the programs fault, but your’s because you chose that mount option months or years ago …
It only mounts filesystems configured in fstab that aren’t already mounted. If it doesn’t mount then something is wrong, and you can correct it easily.
Why would you add your user to root’s group?
Why would it matter if your user already owns the files?
Ah must’ve missed that part, if the users all have the same UID/GID then it’ll work. If not then a group that they all belong to (and g+w) may work, or ugo+rwx, or ACLs.
Sounds like they probably do have the same UID and GID:
The first user always gets a UID and GID of 1000, the second user 1001, and so on. If your users have the same UID/GID then they’re effectively the same user, even if their names (and home dirs) are different.
No. The group your user belongs to is irrelevant if the file or directory is already owned by your user. The group permissions are for the other members of the group which owns the file or directory.
I’ve written an elaborate tutorial about permissions, and I recommend reading it.
The discard mount option has nothing to do with when the system is booted. The discard mount option tells the device to issue a discard operation every time a block is changed on disk.
Not only does this slow down the writing if the underlying device does not support a queued trim, but the instruction may actually be ignored by the device if the amount of cells that would be cleared isn’t big enough.
Therefore, running a weekly trim by way of fstrim.timer is still the recommended way.
Got it with the mount -a. System is not remounting.
Okay, the user is not in the root group. Sorry about that misunderstanding
As all users will have the same UID, going u+rwx is enough, correct?
Starting to remembering stuff. Used to the old bit mask (in this case would be 700).
Thanks to everybody! You have given me valuable tipps and help me get this thing going.
At the same time I’m getting aware, that I have forgotten way too many basics
Will do some reading on the topic, but as always it was fun tinkering around.
Best,
Edward
PS: going to install Manjaro Gnome and XFCE on the other two drives and see if the theory is sound
I tried both noatime and relatime my first SSD on SATA II and could not notice any difference in performance
There is not much information about Linux packages that require relatime to work
and not writing access times is a tiny reduction in disk writes compared to Manjaro package updates
But in the event of a Manjaro update, you will be doubling the amount of written information if you user relatime.
If you have /home on a separate filesystem, then you could mount that one with relatime, but for the rest of the system — if it’s an SSD — I would recommend noatime.
Either way, there isn’t much software anymore that relies on the atime field being updated.
mutt has been mentioned — it uses the atime field to determine whether a particular received email has already been read or not — but that’s about the only one I know of, and mutt is legacy software. Modern email clients use other ways — often database-implemented — of keeping track of such things.
atime updates are either way only ever pertinent on data files — it makes no sense on executable files or configuration files, even though starting an executable file or reading a configuration file — or even cd’ing into a directory — will also cause an update to the atime field in question, because atime does after all stand for “access time”.
