Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I need help to understand how ext3 "ordered" mode works. I've read that this mode journals only metadata, but writes the data to disk before the metadata is written. Does this mean that if the system crashes (i.e., power failure) before the data is written to disk, it is still possible to get filesystem inconsistency because only the metadata exists in the journal on the subsequent boot? Or is ext3 smart enough to know not to replay that transaction from the journal? Or have I totally misunderstood how ordered mode works?
If the system crashes during or before the data (not metadata) is written, it is as if nothing was ever written, because the metadata will never be copied from the journal, so the data will have nothing pointing to it. If the crash happens while the metadata is being copied from the journal, then the actual data is already on the disk, and when the system reboots it simply has to finish writing the journaled metadata to the disk. So you always end up with either all or nothing. Never a partial.
There are some good, detailed explanations (including all of the record keeping so it knows where it was when the crash occured) of this on the web, but I don't have a link handy.
But another question that may not be specific to ext3... When a file is opened for writing, will the future changes be written on the same disk blocks, or will the filesystem allocate new disk blocks?
I wish I knew the answer to that! My guess is it does depend on the filesystem (although ext2 and ext3 probably do it the same way) and it may depend upon the circumstances. For ext2/ext3 the answer may, in part, be tied up with their strategy to minimize fragmentation.
Perhaps somebody with more understanding will post the answer.
Sorry about not having those links handy. IIRC, when I posted that, I had within the previous several weeks seen a couple such articles. In addition to what unspawn posted, this paper presented at the Ottawa Linux Symposium, 20 July, 2000, might (or might not) be of interest. I have only just quickly skimmed it. There is also this IBM Developer Works article, but it looks pretty terse in its explanation.