Tag Info

Hot answers tagged

21

It sounds like you've got a decent grasp on what happened. Yes, because you hard-powered-off the system before your changes were committed to disk, they were there when you booted back up. The system caches all writes before flushing them out to disk. There are several options which control this behavior, all located at /proc/sys/vm/dirty_* [kernel doc]. ...


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 ...


12

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 ...


11

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

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 ...


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

Don't get misled by the fact that only writeback mentions internal filesystem integrity. With 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. In writeback mode, metadata ...


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

All three data journaling modes should leave the filesystem itself fully intact after a power failure. So it should always mount without errors. The difference is only in the data in your files; data=writeback mode may leave stale data (i.e., what was stored in the disk sectors before the writes your app did). data=ordered and data=journaled should not do ...


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

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 ...


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

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

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

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 ...


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

I was also searching for the "Search Everything" tool for linux and discovered "Search Monkey" in the Ubuntu repository. LOVE IT! It's light weight, loads quick, wild card searches produces tons of results instantly, plus it has filters and advanced search methods. I now have my "Everything" search tool back for linux!


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. ...


1

From: https://www.kernel.org/doc/Documentation/filesystems/ext4.txt commit=nrsec (*) Ext4 can be told to sync all its data and metadata every 'nrsec' seconds. The default value is 5 seconds. This means that if you lose your power, you will lose as much as the latest 5 seconds of work (your ...


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 ...



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