Tag Info

Hot answers tagged

16

There are no guarantees. A Journaling File System is more resilient and is less prone to corruption, but not immune. All a journal is is a list of operations which have recently been done to the file system. The crucial part is that the journal entry is made before the operations take place. Most operations have multiple steps. Deleting a file, for example ...


11

No. The most common type of journaling, called metadata journaling, only protects the integrity of the file system, not of data. This includes xfs, and ext3/ext4 in the default data=ordered mode. If a non-journaling file system suffers a crash, it will be checked using fsck on the next boot. fsck scans every inode on the file system, looking for blocks ...


8

You may have a look at rlocate, a reimplementation of locate that is always up-to-date. Another interesting project is recoll which also supports real time indexing and allows you (like beagle) additionally do full-text searches. Finally I should mention doodle which also supports real time indexing. For doodle there are some nice frontends like catfish. ...


7

First, you're right to suspect that “all data” doesn't mean the whole file. In fact, that layer of the filesystem operates on fixed-size file blocks, not on whole files. At that level, it's important to keep a bounded amount of data, so working on whole files (which can be arbitrary large) wouldn't work. Second, there's a misconception in your question. The ...


6

When a file or directory is "deleted" its inode number is removed from the directory which contains the file. You can see the list of inodes that a given directory contains using the tree command. Example $ tree -a -L 1 --inodes . . |-- [9571121] dir1 |-- [9571204] dir2 |-- [9571205] dir3 |-- [9571206] dir4 |-- [9571208] dir5 |-- [9571090] file1 |-- ...


6

Don't get misled by the fact that only writeback mentions internal filesystem integrity. In ext3, whether you use journal, ordered or writeback, file system metadata is always journalled and that means internal file system integrity. The data modes offer a way of control over how ordinary data is written to the file system. So, if data integrity is your main ...


6

A filesystem cannot guarantee the consistency of its filesystem if a power failure occurs, because it does not know what the hardware will do. If a hard drive buffers data for write but tells the OS that it has written the data and does not support the appropriate write barriers, then out-of-order writes can occur where an earlier write has not hit the ...


6

There are many other advantageous features of ext3 and ext4 over ext2, other than journaling. If you are sure that your kernel won't crash, and you won't loose power, then you may choose to disable the journal, which you can do with ext4 and still keep the other benefits, rather than go back to ext2. The journal doesn't cost much though, so generally isn't ...


5

No! As a general rule, if you see a system file and you don't know what it is, don't remove it. Even more generally, if an action requires root permissions and you don't know what it would mean, don't do it. The .sujournal file contains the soft updates journal. The file is not accessed directly as a file; rather, it's space that is reserved for internal ...


3

As you have already noticed, main point is that you cannot prevent your filesystem from all kind of crash. What you can do: On software side, you can use fdatawrites after each important operation (See this 2003 post from Theodore T'so, a main Linux FS Kernel developer. it's still true. There's also this one about a major data loss hidden in older ...


2

I would not blindly rely on what you call good OS that doesn't do kernel panic in each month. The fact is, as systems grow and become more and more complex, there will always be times when some new bugs make their way to the mainline. And I believe this is true for any type of OS or program. Linux may have great stability reputation (as Linus' law about ...


2

Hardware can still randomly glitch or fail from time-to-time. There are so many components involved in writing a file to storage - CPU, RAM, HDD, I/O BUS, etc. It's not just power-outages or reboots that can cause file-system corruption. That said, it's still okay to use EXT2, just don't complain if something goes wrong. I would only use it for non-critical ...


2

$ man mkfs.ext4 The size of the journal must be at least 1024 filesystem blocks (i.e., 1MB if using 1k blocks, 4MB if using 4k blocks, etc.) and may be no more than 102,400 filesystem blocks. I think the default size is 128MB but not sure, that might be dated. Anyways I don't think moving journal to another partition on the same HDD will be an ...


2

The two are in no way equivalent. Disabling the journal does exactly that: turns journaling off. Setting the journal mode to writeback, on the other hand, turns off certain guarantees about file data while assuring metadata consistency through journaling. The data=writeback option in man(8) mount says: Data ordering is not preserved - data may be ...


2

Interesting idea to implement this rooted within the filesystem, but nothing like that exists to my knowledge. Apart from a few add-ons trying to burrow themselves deep enough into the upper fs layers to get an early hold on data (Update: Everything falls into this cathegory itself), I'm afraid you're limited to the less satisfying processes of regular ...


2

You don't need to switch to ext2, you can tune ext3. You can change fsck requirements of a filesystem using tune2fs. A quick look tells me the correct command is tune2fs -c <mount-count>, but see the man page for the details. You can change how data will be written to the ext3 filesystem during mounting. You want either data=journal or data=ordered. ...


2

Try changing which part of the man page you empahsize: writeback Data ordering is not preserved - data may be written into the main filesystem after its metadata has been committed to the journal. This is rumoured to be the highest-throughput option. It guarantees internal filesystem integrity, however it can allow old data to appear in ...


1

You can purge the journal by either un-mounting, or remounting read-only (arguably a good idea when cloning). With ext4 you can also turn off the journal altogether (tune2fs -O ^has_journal), the .journal magic immutable file will be removed automatically. The journal data will still be on the underlying disk of course, so removing the journal and then ...


1

You cannot see the real sum of all write from iotop. iotop row number is limited by your terminal height, processes maybe push off the screen by other processes with more recent I/O activities. Processes that wrote to disk then ended will not stay on the list. (eg. httpd spawn/fork process. Base on PID of httpd, I believe many of httpd child process exit ...


1

Search dmesg output for the timestamp value: dmesg|grep -A 10 905494.178634 10 is the number of lines to show after the match. Increase if needed. It should start with something like: [123456.789012] journal commit I/O error [123456.789042] EXT3-fs (dm-1): error: ext3_put_super: Couldn't clean up the journal You can identify that it's the same event ...


1

Generally speaking... yes, it does make sense. Though you might want to run tune2fs -l /dev/sdXY | egrep "Maxim|Check" to see how those flags are set as it all depends on the version of e2fsprogs used to create the filesystems and/or distribution specific patches applied to e2fsprogs. You might already have MAX_MNT_COUNT and CHECKINTERVAL set to -1 and 0 ...


1

The answer is in most cases no: As already mikel said, most journaling file systems can only protect file metadata (information like the name of a file, its size, its permissions, etc.), not file data (the file's contents). This is happening because protecting file data results in a very slow (in practice useless) file system. Since the journal is also a ...


1

ZFS, which is close but not exactly a journaling filesystem, is guaranteeing by design against corruption after a power failure. It doesn't matter if an ongoing write is interrupted in the middle as in such case, its checksum will be certainly incorrect so the block will be ignored. As the file system is copy on write, the previous correct data (or ...



Only top voted, non community-wiki answers of a minimum length are eligible