Common sense options for /etc/fstab?
 

Hello, I have Slackware 13.37 stable installed in my laptop, and this is my /etc/fstab:

(NOTE: I have LVM over LUKS, volume group being GV_Slack) (and no, I've got no floppy)

As you can see, Slackware doesn't set any mount options for the file systems (mostly). I thought I'd read man mount (and man fstab) :study: and I'd have a few options to choose from. Wrong. :doh:

Then I thought that there must be some common options that people use in fstab all the time, or when they have their HDs partitioned such as me, and that I could ask instead of re-inventing the wheel, and then later tinker fstab even more with the help of the man pages.

So, which options would you recommend for some filesystems (/boot, /, /usr, /home, /tmp and /var in my case) in fstab?.

I've read that /tmp should be "noexec" because of security reasons, and the other filesystems?.

I have many other questions regarding fstab, but they are more... "¿personal?". I'll manage myself at the end, if you don't feel like answering these ones:

May the absence of these options have something to do with my /tmp becoming full with "virtuoso" files or am I supposed to delete them by hand?. Do you think I'm redundant having swap, tmp and tmpfs (I admit I've got only little idea what does this last one serves for)?.

As you can see, I'm very :confused: ...lost with this. Your help will be much appreciated.

Thanks in advance.

Well there really isn't a right answer here. Some people create filesystems as ro (read only) so that users can only access them and view files but not modify anything. Most are set with defaults unless you have a need for something else. If you are looking for more security you can look at implementing ACLs and using acl as your fstab option. But at the end of the day unless you know that you need something specific the defaults will give you what you are looking for. To quote the old and grammatically incorrect adage, "Don't fix what's not broke".

http://www.centos.org/docs/5/html/De...S/ch-acls.html

I'll give you a 'what I'd do' answer; there are many ways of skinning this particular cat, and this is, from where you are my set of preferences and there are other, equally valid, sets of preferences.

The first thing that jumps out is that noatime (or relatime) is not used; for most distros, these days, one of those would be the default. While there is a slight disadvantage in the potential for forensics in noatime, there is an appreciable performance advantage, so most regard that as a worthwhile sacrifice.

I wouldn't have have used ext4 for boot - obviously, it works, these days (once upon a time it didn't), and it doesn't really give an advantage, but having got it, I wouldn't feel any great pressure to change it either.

You say that you have no floppy - you've still got an entry for the floppy, but the cdrom is commented out; is that the right way round, or is that comment character in the wrong place?


Why not? Don't you have any man pages, or the wrong ones, or something else?

The advice about /tmp used to be given very frequently, less so nowadays. I can't quite see why it should have become less good, but possibly we have a load of other, more pressing, things to worry about... Generally, if you already have a separate partition for /tmp, I can't see that it does any harm and it might just do some good.

I have many other questions regarding fstab, but they are more... "¿personal?". I'll manage myself at the end, if you don't feel like answering these ones:

I don't know anything about the virtuoso files, but couldn't you consider something like a script that deletes such files on boot and when the files are more than a certain number of days old, or when there are more than a certain number of them? Well, if nothing else does do anything with these files, you'll have to do something yourself to stop the size growing without limit (well, to the limit of the size available, then something breaks), even if you could make some kind of alerter when this volume exceeds a certain percentage full.

In many distributions, "relatime" is the default compiled into the kernel, and you would have to specify "strictatime" to get the old behavior. The easiest way to tell is to look in /proc/mounts and see of "relatime" shows up for those ext2/3/4 file systems that got mounted with "defaults" in /etc/fstab. Of course you won't see it if this is an older kernel that doesn't support "relatime", but that should not be the case with any recent kernel.

Another useful option is "nodiratime". There is almost never a need to keep track of access times for a directory.

Hello:

First, thanks for your answers. Second, sorry for replying so slow, myself.

Hey, I'm curious to know... what would have you used for /boot?.

BTW, my /home is mostly populated by many small files. Before partitioning, I had heard that ReiserFS is the most appropriate file system for this, but I also had heard that it was/is unmantained, and that Btrfs isn't reliable yet, so I chose ext4. Any advice, here?.

That's how Slackware installation arranged it. I think they leave the floppy entry because of old systems where Slackware is still used (despite it isn't distributed in floppies, AFAIK). Sincerely, I don't know how Slackware is mounting CDs in my system. I think it is doing so via udev. No idea... I only know this works :o

Sorry, I only meant that I wasn't expecting so much information/options when I went to the corresponding man pages. It was a little overwhelming, at first glance.

I think virtuoso files are growing up in /tmp because /tmp wasn't supposed to exist; I mean these files would go into tmpfs, which uses RAM and swap, which of course, are "deleted" when the computer is turned off. Could anyone confirm, please?.

Maybe because when you hibernate your system RAM and tmpfs must be saved in swap... maybe because of this, many recommend that swap should be double the size of RAM? :scratch:

Well, thanks for reading until here. Any help appreciated

ext2: that's the older variant from the ext line, and isn't a journalling filesystem, but I figure you aren't likely to be writing to the boot volume when the power goes down and you have an unclean shutdown, so journalling isn't really an advantage for this volume.

OTOH, I haven't set up a Linux box from scratch for a while now, and the later ext versions may be equally applicable, these days, it is just that when this has occured, I've always used ext2 and I've never had a problem with it.

ext4. ReiserFS had some advanatges, but is old and, at best, semi-maintained. Reiser4 ought to have been the more up-to-date successor, but never really got accepted into the kernel tree (although, there are probably patches). If reiser4 had been accepted and if it was maintained, there probably would have been reason to consider it, but as it is, no.

I'm not sure about BTRFS reliability. fsck for BTRFS was due a couple of months ago, and I don't think it made it on time, although it may have subsequently crept out (...but did it creep out 'feature complete' and fully working, or is it a 'work in progress'?). That has been a show stopper for many people; if you can't repair a volume reliably... On the other hand, I don't know how I'd get evidence as to whether BTRFS itself is reliable.

That said, BTRFS has some atractive features for some applications. On the other hand, there are some (special) situations where it is way slower than ext4. And there are some situations where, with the appropriate choice of options it is significantly faster (particularly if compression helps, and it probably doesn't if you have compression somewhere else (eg, some ssds...although, on the other hand, maybe your ssd is now so much faster, it is no longer worth worrying about this)). I don't think btrfs is currently ready to be your general purpose filesystem, due to the situations in which it is slower than ext4, and maybe it never will be, or maybe we are only a couple of enhancements away. Too difficult to say.

What do you mean by "virtuoso files"?

/tmp can be tmpfs if you like and, yes, all the contents are lost on shutdown or reboot. A few applications (not sure which. File system quotas?) store files permanently in /tmp and these will be upset (but do recover?) when those files disappear. FWIW I have /tmp as part of / (arguably not as robust as having a separate file system for it) and have modified rc.S to delete all files in /tmp as soon as / is mounted with write access. This is safer than deleting files in /tmp during shutdown because there are no processes started which could be writing to /tmp at that time.

On hibernating, everything in memory -- and swap if being used -- is stored in swap but it is compressed so impossible to say exactly what the swap space requirement is. In the worst case scenario of all swap being used and all memory being incompressible (very unlikely) then there would not be enough space in swap to store memory + used swap + small overhead. If this scenario or something near it is probable, a robust setup requires a swap dedicated to hibernating and this will certainly be big enough if it is the size of memory plus swapping swap.

If swap is encrypted then it is not compressible (unless it is decrypted, compressed and encrypted during hibernation ... ?).