2

I put UUID=fb2b6c2e-a8d7-4855-b109-c9717264da8a / ext4 auto,noatime,noload,data=ordered,commit=10,defaults 1 1 in fstab

And now server fails to reboot. It can reboot but reject all kind of connections.

This is what my provider said:

Yeah, the noload option might be problematic... I can't edit /etc/fstab from
single user mode, but I might be able to edit it using one of my pxe boot tools
to enter the filesystem manually. With regards to your request about
/var/log/messages and /var/log/secure, I'm afraid I can't do that for you
(technically, I'm already bordering on managed services by editing your fstab
for you, but I am justifying it as necessary to restore connectivity)...

I search for the purpose of noload option in google

https://www.google.com/search?q=fstab+noload&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

and have no issue. Someone in linux forum says that it disable journaling.

I'm unable to paste the actual error messages without manually typing them out, but I assure you they're not really very descriptive (basically, system indicates that it is unable to remount root in read/write mode, and then errors composed of read/write problems, particularly in /var are printed to the screen)...

It does end in a happy ending:

Your server is back online, and I was able to successfully disable your iptables (which for reference, I did confirm were causing connectivity issues), and I am now able to ssh into your server with the credentials provided earlier in this ticket:

  • 2
    man mount | less -p noload: "Don't load the journal on mounting." There is a caution in the description... – jasonwryan Jan 15 '13 at 2:59
  • Please turn that into an answer. As I suspect. It simply turn of journaling. Not sure what the big deal is. – user4951 Jan 15 '13 at 3:13
4

noload doesn't turn off journaling. It suppresses the loading of the journal, without turning off journaling. As you can imagine, that's usually not a good thing.

noload is mostly useful to mount a disk as read-only without changing it in the slightest way, not even replaying the journal. You can read most data this way, and you can even read all data if the journal was flushed (by calling sync). For example, this is a way of reading from a filesystem that is currently mounted by a hibernated system.

noload may or may not be the cause of your problem, but in any case it's a very bad idea, and definitely not something to use in /etc/fstab.

  • We have 2 answers with totally different opinions. Got sources? – user4951 Jan 16 '13 at 1:16
  • @JimThio I don't see any conflict between jasonwryan's answer and mine. We've explained things in a different way. – Gilles Jan 16 '13 at 1:19
5

As man mount describes it:

norecovery/noload
Don't load the journal on mounting. Note that if the filesystem was not unmounted cleanly, skipping the journal replay will lead to the filesystem containing inconsistencies that can lead to any number of problems.

You should really be only using this option to mount a filesystem so that you can attempt a repair with fsck. It should not be part of a standard /etc/fstab entry for a journalling filesystem like ext4.

  • and doing reboot means I am not unmounting cleanly? – user4951 Jan 15 '13 at 6:33
  • Not necessarily; but I would fsck the filesystem (on the next boot) now that you have it back on-line just to make sure everything is in order... – jasonwryan Jan 15 '13 at 6:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.