Talk:Journaling file system

message: The benefit of a journaling file system has been well made, but there is no section which specifically compares benefits with limitations.  I don't want to attempt this myself on a subject I came to the page to find out about.  (^_-)
But this page may give some ideas... http://support.apple.com/kb/HT2355
There is a section: "When Should Journaling Be Used?" which helped me.
88.96.159.86 (talk) 11:06, 4 June 2011 (UTC)
thread_title:  Pros and Cons 

message: Properly this is a "Journalized" file system according to the dictionary (See OED entry for Journal and for Journalize). Journal(l)ing is a Linuxism and incorrect English 81.2.110.250 (talk) 23:17, 30 April 2008 (UTC)
thread_title:  Spelling And Words 

message: Would it be correct or incorrect to refer to the GoBack product as a Journaling file system? --Rebroad 14:38, 25 May 2005 (UTC)
thread_title: [[GoBack]]

message: Theres an interesting comment on this issue by an ext3 developer, pointing out that logical journalling assumes disk block writes are atomic (they either happen or don't), whereas at least PC hardware is not so nice.  <http://zork.net/~nick/mail/why-reiserfs-is-teh-sukc>. —The preceding unsigned comment was added by 217.64.116.8 (talk • contribs) 20:38, May 24, 2006  (UTC)
I'd  be interested to see examples of  Physical and Logical journalling. I know quite a lot of  filesystems journal metadata, but FreeBSD's  gjournal is the only example of full data journalling I'm aware of.  —Preceding unsigned comment added by 87.81.140.128 (talk) 01:03, 26 August 2010 (UTC)
thread_title: Physical vs logical journalling

message: Could someone please elucidate on the "Why" of journaled filesystems, in addition to the what and how?
Rough answer: When there is an improper shutdown (e.g. power cut), on the subsequent boot it is necessary to check the filesystem to ensure that it is still safe to use. On a large filesystem without journalling, this means a lengthy filesystem check during boot. Journalling changes how the filesystem is written so that it suffices to read through the journal (since any write to the rest of the filesystem will be preceded by a a write to the journal, so we need only check each entry in the journal and see if it has succeeded or not). Chalisque (talk) 21:41, 22 January 2016 (UTC)
thread_title: Why vs. What

message: Since the most commonly know use of journaling is in HFS+ file systems, it might be appropriate to cite the following document for this article.
http://docs.info.apple.com/article.html?artnum=107249
--Zerocool3001 20:31, 26 July 2007 (UTC)
thread_title:  Available Sources 

message: *Citation: A journaled file system maintains a journal of the changes it intends to make, ahead of time. After a crash, recovery simply involves replaying changes from this journal until the file system is consistent again.
**What I currently only see is that all problems of inconsistency are moved to the journal. What makes sure that the journal itself is not written to disk in an inconsistent manner? That is, when the system crashes (power loss etc.) while the journal is being written, isn't it left in an inconsistent state, giving rise to corrupt file systems the next time the journal is used to update the FS? --Abdull (talk) 09:54, 8 August 2008 (UTC)
replies: text: Is it correct to say that operations that require more than a single write to the disk are converted into one write to the journal? So either the journal was written successfully or not, and therefore any operations that were written to the journal, but were half-completed on the disk, can be completed and then removed from the journal?  — Preceding unsigned comment added by 58.152.137.30 (talk) 19:47, 21 June 2011 (UTC)
replies: text: No, because logging a large change in the journal may actually require multiple writes to multiple disk blocks.  The journal can still give an atomicity guarantee, though, because it appends checksums to each and every change that it logs.  When remounting after a crash, it just skips over changes with invalid checksums.—213.239.210.250 (talk) 05:48, 24 June 2011 (UTC)
thread_title:  Moving, not solving problems? 

message: I don't know much about this, but could there be a section on the cost of journaling? PDBailey (talk) 15:44, 7 April 2009 (UTC)
thread_title:  cost? 

message: "recovery simply involves reading the journal from the file system and replaying changes from this journal until the file system is consistent"
Where do you start reading the journal, that is, at what point? How is this determined? Is it possible to backtrack from the end to find the last change that had succeeded? Also, the fs is consistent by definition at all times. It's a question of performing the changes that weren't successful before the crash. --213.130.252.119 (talk) 01:21, 2 May 2010 (UTC)
thread_title:  Technical detail needs some clarifying 

message: "... Such file systems, however, were not feasible until the recent discovery of the necessary copy-on-write-friendly data structures" and the reference to a 2009 paper on BTRFS is not accurate. ZFS was made available in November of 2005 and is a copy-on-write filesystem. Tpenta (talk) 06:58, 30 December 2010 (UTC)
thread_title:  Copy on Write filesystems not possible until BTRFS paper? 

message: The current comparison if logical vs. physical logs is inaccurate. It seems to imply that physical logs always log all data (as opposed to only meta-data). This is not true, e.g. ext3 uses a physical log, but is generally run in a meta-data only journalling mode (data=ordered or data=writeback). The difference with file systems using a logical journal is that ext3 always logs the full meta-data block, while file systems with a logical journal will only log a record describing which fields in the meta-data block have to be updated. Logical journals would in theory require less I/O bandwidth but more CPU time.
The confusion may have arisen because physical journalling seems to be a prerequisite for full data journalling (data=journal). —Ruud 19:00, 8 December 2011 (UTC)
thread_title:  Physical vs. logical 

message: It sounds like the description of copy-on-write and "soft update" are pretty similar. Is that accurate? Should the two be merged (for example, CoW merged into soft update as a second example to UFS)?  — Preceding unsigned comment added by 152.8.99.118 (talk) 14:49, 13 May 2013 (UTC)
thread_title:  Alternatives