7

I'm verry new to Linux. I have a Raspberry Pi 4 device with Raspberry Pi OS Lite. I use this with 4 HDDs conected to USB as a NAS. The hard drives were formatted in NTFS because I used them in Windows until now. But I noticed that the transfer goes very slowly in Linux, so I converted one to EXT4. Now it's much better... but a new problem appeared. The EXT4 disk it no longer enters sleep mode, because it is accessed by the system almost continuously to write in that journal. I disable it with tune2fs -O ^has_journal /dev/sda1 and now my drive enter sleep mode again. As I don't know almost anything about Linux, I want to ask you how bad is to run my system with journaling disabled ? What could happen? What are the cases that could lead to data corruption ? I plan to use a UPS with that system. Does it helps ? With journaling disabled, my drives will fail only after a sudden power outage or it can happen in normal operation too ? The journaling will be disabled only in those 4 external hard drives, not to the system one. The data is somehow important, but not vital. And it will accessed quite rarely...

Improve this question
4
  • 5
    This is likely an XY problem. Journalling doesn't generate any write traffic on its own, whatever you see written by jbd2 is triggered by writes to elsewhere on the disk. The issue you see is likely due to some other ext4 feature which depends on having a journal, like lazy initialization of filesystem structures. Did you perhaps observe this "disk not sleeping" issue only shortly after mounting a new filesystem for the first time? Commented Dec 25, 2022 at 22:43
  • @TooTea misdiagnosis isn't really the same concept as XY. Commented Dec 26, 2022 at 21:28
  • @PhilipCouling Right,and that same Google search yields results showing that the root cause was lazy itable init. Commented Dec 26, 2022 at 21:28
  • @TooTea yeah I read "XY" and thought you meant the OP was asking the wrong question. They are not, and I don't think that's what you meant. But that is the general inference of XY. Commented Dec 26, 2022 at 21:50

3 Answers 3

Reset to default
1

Actually, the NAS with UPS is a perfect place for disabling journaling.

The primary benefit (and the goal) of journaling FS is to save data if HDD loses power. The idea is that to write data into a proper place on HDD takes some time and several physical operation of disk access, while writing changes to journaling log first is much faster. And once the FS driver sees a period of inactivity from application - it dumps data from the log into the FS.

So disabling journaling leads to a slower write to the disk. Now, the driver knows that it does not have a convenient location for a quick storage and takes time to properly organize data on the HDD.

In case of the NAS, user is already expecting a longer read/write operation and not an immediate response as from the built-in HDD (or even SSD). So slowness of writing will go unnoticed by the human. Especially since the actual slowdown is really in less then a second.

You can also look at the wiki's article, it explains the journaling in more details and have links to actual textbooks discussing it: https://en.wikipedia.org/wiki/Journaling_file_system

Improve this answer
5
  • 1
    They say: "Updating file systems to reflect changes to files and directories usually requires many separate write operations. This makes it possible for an interruption (like a power failure or system crash) between writes to leave data structures in an invalid intermediate state." -- So my drive will be corrupted only when the power failure happnes when something is written on the disk ? If the drive is idle or in sleep mode and the power is cut off can something bad happen ? Commented Dec 25, 2022 at 13:27
  • 8
    -1 This is misleading or just wrong on several points. The primary purpose of journalling is to make sure the filesystem stays consistent even across crashes (not just power cuts, but also random freezes and reboots for whatever reason, kernel panics, accidental disconnects of the USB link etc.). Without a journal, any of these means you absolutely have to run fsck and pray it manages to get the filesystem into a usable state again (might take ages to do so). Journalling is not a performance optimization, having to write stuff twice obviously takes a while. Commented Dec 25, 2022 at 22:50
  • 4
    And honestly, what on Earth do you mean by "[driver] takes time to properly organize data"? The data format on the disk is exactly the same with or without a journal, having a journal only means doing extra bookkeeping in addition to writing stuff to the usual places. Commented Dec 25, 2022 at 22:52
  • 1
    Agreed, the first two sentences are alright, the remainder is not. The purpose of the journal is to improve consistency by acting as a write-ahead log. There isn't a special safe-slow path that's used when journaling is turned off; the journal write is just skipped, which is faster. Commented Dec 26, 2022 at 4:00
  • 1
    fsck is strongly recommended to be run after a crash even with journalling enabled. Time and again people misunderstand ext4 journalling. It's not a panacea for system crashes. Commented Dec 26, 2022 at 9:46
1

I've seen a few sporadic reports of the behaviour you describe. Eg: here https://superuser.com/a/1046164

As TooTea points out, this may be related to lazy initialisation but some reports suggest this might still go on for a long time.

The answer referenced above suggests reformatting your drive to fix it. You may also want to mount with "noatome".

The answer to how safe it is to turn off journaling is quite subjective. I would never base any decision on the reliability of your power supply. They are one thing most prone to fail. And anything can fail. Other failures in your system can cause it to just stop too.

I've had things fail after 8 years "running just fine". Then again I've had thing fail in less that 6 months.

The only thing you should base your decision on is how much do you value your data, and whether you are sure your backups will always be sufficient.

NAS for home use quite often hold personal data like photos which are irreplaceable, deeply upsetting to lose, and usually not backed up. Though you definitely should back up.

In short, it's your data. It might not fail tomorrow or this year, but you are adding a risk by disabling journaling.

Journaling is about data security. There's never a complete guarantee that you data is safe. The true aim of journaling is to make updates to the file system atomic (or as close to that as possible).

Basically it writes the intent of what it wants to change before starting to make that change. In a failure, either:

  • the journal entry was not complete and can be ignored
  • the journal entry was complete and can be used to finish updating the actual file system
  • The file system write completed and the journal entry can effectively be ignored.

If anything causes your system to crash then the file system should be consistent. Obviously hardware itself can write something different and or just flip bits (google bot rot) but outside of that,. Journaling is very effective at reducing the risk of corruption and data loss.

Improve this answer
0

First things first: journalling on ext4 is not mandatory it's optional.

Secondly: journalling is not about making the filesystem more resilient, it's about making recovery after e.g. a power loss or kernel panic faster.

Thirdly: I've had it disabled since forever because 1) I've got no issues with power and my systems are quite stable 2) journalling slows down write operations 3) journalling greatly increases the amount of data which is being written to the disk which is not good for SSD storage.

What are the cases that could lead to data corruption?

The absence of journalling itself will never lead to data corruption.

With journaling disabled, my drives will fail only after a sudden power outage or it can happen in normal operation too?

Fail how? Physically? Will happen regardless of journalling. Fail, as in a filesystem corruption? Journalling does not prevent it, it just deals with it faster.

Improve this answer
5
  • 1
    "resilient, it's about making recovery after e.g. a power loss or kernel panic faster." Journaling makes changes effectively atomic. At each point in time during a write, the file system structures are either completely written, or there is sufficient data in the journal to complete. Without journaling you can have a partial write that is unrecoverable and this can cause unrecoverable data loss. It is not just about speed. Commented Dec 26, 2022 at 11:42
  • AFAIK that requires storage which guarantees atomic writes which is not always the case. Commented Dec 26, 2022 at 11:44
  • That's complicated. But the technique here is to massively reduce the amount of data required to make that "atomic" switch. SSDs are almost all atomic AFAIK because they write the block before updating wear levelling mapping. Magnetic is a little more complicated. But write order does a lot to reduce the risk. Commented Dec 26, 2022 at 12:16
  • 1
    If you have one of those broken drives that cheat and report completion before data actually hits stable storage,all bets are off and no amount of filesystem magic will help you. The only fix is to return such a drive and get a saner one. If you have a drive that actually honours flushes,journalling will keep the FS usable (barring HW or SW bugs). Commented Dec 26, 2022 at 19:00
  • 1
    I think your second paragraph originated from a few words in this written by the author of ext3. He says "The primary motivation behind this new filesystem design for Linux was to eliminate enormously long filesystem recovery times". But taking those words out of context ignores a significant passage on "Filesystem Reliability". It would be a mistake to use this document to infer journaling is not [also] about making a filesystem more resilience. Commented Mar 9, 2023 at 6:56

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.