Fstab accidentally altered - does this now look acceptable?

Tripsun · 2011-03-27 02:00:35

Hi,
my /etc/fstab was inadvertently altered and I had to recreate most of it from memory. I am able to boot into my system so this "works" but I do not believe it was identical to my prior version or if someone has any suggestions for improvements to the options. I am sure all of the partitions are correctly linked to the entry (I had a list of it from my install):

# 
# /etc/fstab: static file system information
#
# <file system>        <dir>         <type>    <options>          <dump> <pass>
devpts                 /dev/pts      devpts    defaults            0      0
shm                    /dev/shm      tmpfs     nodev,nosuid        0      0

/dev/sda5 /boot ext3 defaults,noatime 0 1
/dev/sda10 swap swap defaults,noatime 0 0
/dev/sda3 / ext3 defaults,noatime 0 1
/dev/sda8 /home ext3 defaults,noatime 0 1
/dev/sda9 /usr ext3 defaults,noatime 0 1
/dev/sda7 /tmp ext3 defaults,noatime 0 1
/dev/sda6 /var reiserfs defaults,noatime 0 1

Thank you a lot!

Last edited by Tripsun (2011-03-27 02:04:11)

lives2evil · 2011-03-27 02:05:21

If it works and you believe it's correct. What more exactly are you asking?

Tripsun · 2011-03-27 02:14:03

Well all I am sure of is that /dev/sda* is linked correctly to the /,/home, etc.

The rest I am very unsure about (i.e. the options, dump, pass). For example, on the fstab page on the arch wiki, the boot partition only has defaults (not noatime). As I am not that experienced with linux so I don't fully comprehend the various options, like the implications of using relatime vs noatime, or whether to use 0,1,2 for the dump/pass.

Last edited by Tripsun (2011-03-27 02:22:11)

lives2evil · 2011-03-27 02:22:15

Your fstab seems pretty OK to me. Nothing wrong whatsoever.
noatime is usually used on laptop to reduce harddisk activitives, nothing special (it means "no access time" if you ask me).

jac · 2011-03-27 11:25:29

According to the fstab manpage (yep, there are ones for configuration files too ) only the root filesystem should have the last field set to 1. I'm guessing what you have won't hurt anything, just slow down the process as all your partitions are checked at the same time.

lives2evil · 2011-03-27 11:39:34

In fact, by default arch set the last field (pass) to 1 for all partitions (except swap of course).

Ramses de Norre · 2011-03-27 11:43:45

Some notes:

* Add an errors=remount-ro option to important partitions to avoid data corruption.
* Use persistent labelling (UUIDs or labels) to avoid dev nodes swapping names making your system unable to boot, see the wiki.
* noatime is not an accepted option for swap AFAIK. And it is useless even if it is accepted.
* Use nodev, nosuid and noexec wherever possible.
* Set pass to 2 on partitions other than /

HTH

JokerBoy · 2011-03-27 14:13:28

and maybe barrier=flush for reiserfs partitions.

Tripsun · 2011-03-27 17:09:28

Thank you for all the responses. How does this look? I will add persistent labelling soon.

# 
# /etc/fstab: static file system information
#
# <file system>        <dir>         <type>    <options>          <dump> <pass>
devpts                 /dev/pts      devpts    defaults            0      0
shm                    /dev/shm      tmpfs     nodev,nosuid        0      0

/dev/sda5 /boot ext3 defaults,noatime 0 2 
/dev/sda10 swap swap defaults 0 0
/dev/sda3 / ext3 defaults,noatime,errors=remount-ro 0 1
/dev/sda8 /home ext3 defaults,noatime,nosuid,nodev,errors=remount-ro 0 2
/dev/sda9 /usr ext3 defaults,noatime,nodev,errors=remount-ro 0 2
/dev/sda7 /tmp ext3 defaults,noatime,nodev,nosuid,noexec 0 2
/dev/sda6 /var reiserfs defaults,noatime,nodev,nosuid,errors=remount-ro 0 2

I got the suggestions on where to put nosuid,nodev,noexec here so it would be great if someone could verify to make sure this is valid before I implement it: http://www.cyberciti.biz/tips/the-impor … tions.html

JokerBoy · 2011-03-27 17:49:54

reiserfs doesn't support errors=remount-ro

Leonid.I · 2011-03-27 18:13:33

/var should be noexec too (this is arch-specific, other distros may need to exec something from /var)... and again switch to UUID (see the output of /sbin/blkid).

Also, I wonder what is the size of your /var, because reiserfs is only effective when dealing with small files, and you might have pretty large packages in /var/cache/pacman/pkg. Therefore, I would recommend mounting only (small ~ 100Mb) /var/lib as reiserfs, and /var -- as ext4/jfs. Actually, this makes pacman's (<3.5) operations almost instanteneous on an average HDD.

Tripsun · 2011-03-27 19:34:16

Thanks for the help and I will add UUID soon. As far as /var is concerned, is it possible to switch the filesystem since I have already made it reiserfs?

Also, what does barrier=flush do for reiserfs (can't find much from google search). Here is an updated version:

# 
# /etc/fstab: static file system information
#
# <file system>        <dir>         <type>    <options>          <dump> <pass>
devpts                 /dev/pts      devpts    defaults            0      0
shm                    /dev/shm      tmpfs     nodev,nosuid        0      0

/dev/sda5 /boot ext3 defaults,noatime 0 2 
/dev/sda10 swap swap defaults 0 0
/dev/sda3 / ext3 defaults,noatime,errors=remount-ro 0 1
/dev/sda8 /home ext3 defaults,noatime,nosuid,nodev,errors=remount-ro 0 2
/dev/sda9 /usr ext3 defaults,noatime,nodev,errors=remount-ro 0 2
/dev/sda7 /tmp ext3 defaults,noatime,nodev,nosuid,noexec 0 2
/dev/sda6 /var reiserfs defaults,noatime,nodev,nosuid,noexec,barrier=flush 0 2

EDIT: I added persistent labelling. I removed all of the /dev/sda* and replaced with UUID=[alphanumeric code] to match output of "sudo blkid"

Last edited by Tripsun (2011-03-28 01:49:47)

JokerBoy · 2011-03-27 20:45:06

man mount

Mount options for reiserfs
..
barrier=none / barrier=flush
              This  enables/disables  the use of write barriers in the journaling code.  barrier=none disables it, barrier=flush enables
              it. Write barriers enforce proper on-disk ordering of journal commits, making volatile disk write caches safe to  use,  at
              some  performance  penalty.  The reiserfs filesystem does not enable write barriers by default. Be sure to enable barriers
              unless your disks are battery-backed one way or another. Otherwise you risk filesystem corruption in case of  power  fail‐
              ure.
..

Leonid.I · 2011-03-27 21:19:09

Also http://www.linuxtopia.org/online_books/ … ebarr.html.

I don't think that you can switch from reiser to ext w/o reformatting, so I would back up /var with rsync (not with cp) in order to preserve timestamps. But I would also think twice, if the system is not freshly installed, because you may corrupt for instance pacman db...

Why do you need journaling (ext3) on /tmp, if it is being flushed every reboot? I would use ext2 for /tmp.

JokerBoy · 2011-03-27 21:57:59

I rather use tmpfs for /tmp, and I do.

Tripsun · 2011-03-28 00:54:21

Well I would like to disable journaling then for /tmp since I agree that it is unnecessary. To convert ext3 -> ext2 would I just need to do the following:

#sudo umount /dev/sda7
#sudo tune2fs -O ^has_journal /dev/sda7
#sudo e2fsck /dev/sda7

And then change ext3 to ext2 in /etc/fstab? Or maybe it would be safer to do it from a live cd while nothing is mounted?

I think I will stick with reiserfs for /var for the time being. Pacman 3.5 is very quick and I have no complaints. I don't know that it is worth risking corruption for a small performance improvement. Again, thanks for all the help!

Last edited by Tripsun (2011-03-28 00:56:28)

milomouse · 2011-03-28 01:23:50

edit: let me rephrase that... /dev/shm on /tmp

Last edited by milomouse (2011-03-28 01:27:33)

Leonid.I · 2011-03-28 04:42:20

Tripsun wrote:

Or maybe it would be safer to do it from a live cd while nothing is mounted?

Yes, that's a good idea.

JokerBoy wrote:

I rather use tmpfs for /tmp, and I do.

Well, I haven't seen any situation, when system performance was bounded by I/O from /tmp... thus I wouldn't mount it to RAM, or bind-mount /dev/shm to /tmp. Data stored in /tmp may prove useful in an event of a crash.

Tripsun · 2011-03-28 05:17:48

So those instructions look correct though?

And while I am at it, wouldn't it make sense to have /boot as ext2. The journaling feature is not at all used on boot since the partition is never changed. Just wastes space for the journal...

Leonid.I · 2011-03-28 17:32:36

Tripsun wrote:

So those instructions look correct though?
And while I am at it, wouldn't it make sense to have /boot as ext2. The journaling feature is not at all used on boot since the partition is never changed. Just wastes space for the journal...

Yes to the 1st question and kind of (as in "I wouldn't bother", because /boot still contains kernel images, which are recreated at each kernel update) to the 2nd one

Last edited by Leonid.I (2011-03-28 17:33:48)

Tripsun · 2011-03-28 18:59:05

Ok thank you for your continued support. Last couple of questions. Before I do this change, would you highly recommend it/will I see any noticeable difference for what I am doing? Is there any risk that I corrupt some the /tmp partition?

Second, while we're on the subject of altering file systems. Would you recommend moving from ext3--> ext4 for the other file systems? Most of the reviews that I read seem to highlight the boost in performance but is it noticeable? The wiki states that booting from ext4 is not officially supported (although I suppose this would only be an issue if I make /boot ext4.

Leonid.I · 2011-03-28 20:42:12

No problem

Generally, I usually try to avoid deep FS layout changes after the installation -- such decisions are made at install time.

Regarding /tmp and the question of removing journal vs keeping it, I usually prefer the former, even if the pros (e.g. performance) are not readily visible, simply because there are two less jbd2/ext4-dio-unwrit processes to run and there is no risk of data corruption.

Regarding switching from ext3 to ext4 on a working system, I don't think it's a good idea due to following reasons:
1. The system is up and running fine (?), and works as expected (?).
2. Benchmarks pointing out performance boosts are inconclusive; these improvements depend on the task at hand, and usually negligible in general-purpose systems.
3. Many consider ext4 as an intermediate step to btrfs, so if you have to, switch to btrfs directly (after some time).

Finally, there is no problem using ext4 as /boot -- I have it on 4 systems with no problems.

Arch Linux

#1 2011-03-27 02:00:35

Fstab accidentally altered - does this now look acceptable?

#2 2011-03-27 02:05:21

Re: Fstab accidentally altered - does this now look acceptable?

#3 2011-03-27 02:14:03

Re: Fstab accidentally altered - does this now look acceptable?

#4 2011-03-27 02:22:15

Re: Fstab accidentally altered - does this now look acceptable?

#5 2011-03-27 11:25:29

Re: Fstab accidentally altered - does this now look acceptable?

#6 2011-03-27 11:39:34

Re: Fstab accidentally altered - does this now look acceptable?

#7 2011-03-27 11:43:45

Re: Fstab accidentally altered - does this now look acceptable?

#8 2011-03-27 14:13:28

Re: Fstab accidentally altered - does this now look acceptable?

#9 2011-03-27 17:09:28

Re: Fstab accidentally altered - does this now look acceptable?

#10 2011-03-27 17:49:54

Re: Fstab accidentally altered - does this now look acceptable?

#11 2011-03-27 18:13:33

Re: Fstab accidentally altered - does this now look acceptable?

#12 2011-03-27 19:34:16

Re: Fstab accidentally altered - does this now look acceptable?

#13 2011-03-27 20:45:06

Re: Fstab accidentally altered - does this now look acceptable?

#14 2011-03-27 21:19:09

Re: Fstab accidentally altered - does this now look acceptable?

#15 2011-03-27 21:57:59

Re: Fstab accidentally altered - does this now look acceptable?

#16 2011-03-28 00:54:21

Re: Fstab accidentally altered - does this now look acceptable?

#17 2011-03-28 01:23:50

Re: Fstab accidentally altered - does this now look acceptable?

#18 2011-03-28 04:42:20

Re: Fstab accidentally altered - does this now look acceptable?

#19 2011-03-28 05:17:48

Re: Fstab accidentally altered - does this now look acceptable?

#20 2011-03-28 17:32:36

Re: Fstab accidentally altered - does this now look acceptable?

#21 2011-03-28 18:59:05

Re: Fstab accidentally altered - does this now look acceptable?

#22 2011-03-28 20:42:12

Re: Fstab accidentally altered - does this now look acceptable?

Board footer