journalling issue -- plz help

[Maaz]

Dea Gurus

OS: rhl 9.0
fs: ext3
#cat /etc/fstab
LABEL=/tmp /tmp ext3 default 1 1

i created a file via touch
#touch /tmp/test.txt
then
#vi /tmp/test.txt and did some editing, but without saving the data, i myself reboot my system, and did
#vi -r /tmp/test.txt, and i found all my un-save data.. great :)
So i wana know that is it due to journalling filesystem i.e. ext3, or is it simple the text editor(vi/vim) feature ?

i think its simply the vi feature, bcause when i did the same ... but the text editor was 'gedit' intead of vim.. my all un-save data was lost.

one more question is ext3 not a journalling fs ? if its a journalling fs then why unsave data lost ?

I even use the option in fstab as:
LABEL=/tmp /tmp ext3 data=journal,default 1 1
and
LABEL=/tmp /tmp ext3 data=writeback,default 1 1
but if i unsave my data, and reboot the system, and open the file with gedit(gui), i didnt found the unsave data

Hope you people will help me in this matter

Thanks in Advance.

Regards
Maaz

[Uwe Zessin · Accepted solution]

Unsaved data is, well not safe on disk ;-)

The vi editor apparently does its own journalling and it makes sure that the data really is on the disk.

Having a journalling file system (FS) mostly means that the FS tracks which meta data changes have been in process when the system went down. This allows a fast rollback of the FS into a consistent state and saves you from waiting a long time for a full file system check to complete.

[Kodjo Agbenu]

Hi Maaz,

Vi uses a sort of temporary file mechanism. For example : open a new file with vi, then without saving open another command-line console and type :
ls -al .*swp

If the system crashes (or is rebooted) while still running vi, the .swp file remains.

Gedit does not use this mechanism.

Now about ext3 : this is actually a journalled filesystem. The journalling mechanism is not at application-level (ex: vi or gedit), but at filesystem level. To understand, you need to know what is a transaction.

To simplify, let's say that to create a new file, you have to store 1/ the content of the file, 2. the information that a new file have been created. The constraint here is the following : you must either complete 1/ and 2/ , or nothing. You cannot have 1/ completed without 2/ or vice-versa.
The sequence of action 1/ and action 2/ is called a transaction. To guarantee the "atomicity" of a transaction (= completing 1/ and 2/ or nothing), filesystem mechanism implements a journal that record intermediate steps of the transaction.
To simplify :

=> Log : "I'm starting a new transaction"
=> Log : "I'm going to perform 1/"
=> Do 1/
=> Log : "1/ completed"
=> Log : "I'm going to perform 2/"
=> Do 2/
=> Log : "2/ completed"
=> Log : "Transaction completed"

If the system crashes, the filesystem check (fsck) on a journalled filesystem verifies the journal (the log) and seek for transactions started but not completed, in order to either un-do intermediate steps, or go forward and terminate the transaction.

Hope this is clear. Of course, this is very simplified, compared to the complexity of a real filesystem journalling mechanism.

Good lcuk,
Kodjo

[Maaz]

Dear Uwe Zessin, I m highly thankful to u for the reply/help. Nice Help.

Dear Kodjo Agbenu, u provide a marvelous help. I m highly Thankful to u for such a Marvelous, Nice and Great help

Regards
Maaz