LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices


Reply
  Search this Thread
Old 09-05-2007, 03:12 PM   #1
lotuseclat79
LQ Newbie
 
Registered: Sep 2007
Posts: 7

Rep: Reputation: 0
mount command failed to apply journal


Recently, I have experienced a problem where the mount command apparently failed to apply the journal. I have experienced this several times.

Let me explain further. I am currently using a Live CD environment. I do have a Linux variant installed on one of my SATA hard drives. When I power up my computer, all disks are spinning.

I first use mkdir from the root account to make the mount point. Then I issue the mount command with the -o sync option to mount the ext3 journaled file system of the Linux hard drive. If all goes well, I am able to copy my initialization scripts for my Live CD environment into RAM (1GB).

After a Live CD session, I often save my Firefox environment on the Linux hard drive. Occasionally, I experience the problem on the next mount which may be well over the max-mount-count in the superblock for the hard drive, fsck not having been run against it nor the Linux hard drive booted up. I have issued the dumpe2fs command to learn more about the data in the superblock from the Live CD environment and saved the results for later comparison.

The next time I experience the problem I will run dumpe2fs again to collect more data and compare it with what I have saved.

If, immediately after the incident occurs, I use an earlier version of the Live CD release, the earlier version does not have this problem. After that I can again access by data stored on the Linux hard drive with my current Live CD - usually without having to run an fsck and actually booting up my Linux hard drive - but, at least once or twice I did do that.

The reason I know the journal is not being applied is that the latest file indicated when the incident occurs is dated the same as the creation date of the file system. All of my files that reconstitute my Live CD environment are not accessible when this incident occurs.

My question is why would the journal not be able to be applied? Is for some reason the Linux hard drive being marked dirty after I save to it? If so, then why does the earlier Live CD not exhibit this problem? What are all of the reasons for a journal not to be applied?

-- Tom
 
Old 09-05-2007, 03:58 PM   #2
jailbait
LQ Guru
 
Registered: Feb 2003
Location: Mineral, Virginia
Distribution: Debian 8
Posts: 7,893

Rep: Reputation: 339Reputation: 339Reputation: 339Reputation: 339
"My question is why would the journal not be able to be applied?"

There was a bug in the 2.4 kernel where journaling in ext3 did not work properly when running in synch mode. Supposedly this got fixed in the 2.6 kernel but I cannot prove that one way or the other. What kernel versions are you running on the 2 live CDs and on the hard drive? You might take a look at the kernel mailing list to see if the bug is active in your kernels.

"Occasionally, I experience the problem on the next mount which may be well over the max-mount-count in the superblock for the hard drive,"

You can use the tune2fs command to increase the maximum mount count to where it is less of a nuisance.

-------------------
Steve Stites
 
Old 09-05-2007, 04:24 PM   #3
lotuseclat79
LQ Newbie
 
Registered: Sep 2007
Posts: 7

Original Poster
Rep: Reputation: 0
The Live CD I run is a knockoff of Ubuntu Fiesty Fawn (7.04) called Ultimate Ubuntu 1.4. The earlier Live CD release is Ubuntu Dapper Drake 6.0.6 LTS. Fiesty uses Linux kernel 2.6.20-16-generic, and Dapper uses Linux kernel 2.6.15.6 I believe. The Linux hard drive is Fedora Core 3 running Linux kernel 2.6.10-1.

Where would I be able to find the kernel mailing list - just to read or search rather than subscribe to it?

The last incident had a maximum-mount-count of 30 and a mount-count of 72, so I am not particularly concerned about that unless it is a factor in causing the occurence of this problem.

Thanks for your reply jailbait,

-- Tom
 
Old 09-05-2007, 07:12 PM   #4
jailbait
LQ Guru
 
Registered: Feb 2003
Location: Mineral, Virginia
Distribution: Debian 8
Posts: 7,893

Rep: Reputation: 339Reputation: 339Reputation: 339Reputation: 339
Quote:
Originally Posted by lotuseclat79 View Post
Where would I be able to find the kernel mailing list - just to read or search rather than subscribe to it?
-- Tom
Probably the best place to look for a kernel bug is:

http://bugzilla.kernel.org/

The kernel mailing list is at:

lkml.org

-----------------
Steve Stites
 
Old 09-07-2007, 02:27 PM   #5
lotuseclat79
LQ Newbie
 
Registered: Sep 2007
Posts: 7

Original Poster
Rep: Reputation: 0
Another occurence of this problem occurred this AM. Armed with dumpe2fs I was able to collect additional data related to fiesty vs dapper and the original FC3 Linux disk. Note: all dumpd2fs text files are actually generated by piping the output of dumpd2fs and saving the output of a head -35 command to the file.

Since I know how to throw the cdrecord command to create an isofs collection of files and identify the (bus, target, lun) of the cdrom and most importantly not confuse it with my dvd-ram drive from which Ubuntu Live CD is launched - I was able to collect 7 different files:

The sequence of events/files recorded were:
1) a dumpe2fs of fiesty immediately after the event: fiesty-dumpe2fs.txt
Note: I did see the (command generated: ls -lt > rootls.txt) file in /root which was taken on 8/7/07, and when the journal is applied, it is, of course, not visible.
2) a dumpe2fs of dapper after 1) recorded in file: dapper-dumpe2fs.txt
Note: Dapper doesn't smoothly execute cdrecord -scanbus w/o help, and I used:
# cdrecord -scanbus dev=ATAPI (to get the proper id of the cdrom)
Note: Dapper, once again, did not have a problem mounting the journal, and I was able to record to size of the /root/mbox file when the problem does not occur. The file rootls-lt-mbox.txt records the current size w/o the problem which was generated and recorded with the ls -lt command in the file: ls-lt-root-mbox.txt.
3) Next, I again tried to boot with the Fiesty Live CD and no, it did not work immmediately after the Dapper Live CD had worked. Here I took another dumpe2fs: fiesty-2nd-dumpe2fs.txt.
4) Next, I booted up the Linux hard drive FC3 filesystem which ran an fsck since the file system had not been checked according to it for some 94 mounts without being fsck'ed.
5) I did not login, and simply rebooted the system back up with the Fiesty Live CD - this time it did not experience the problem after the mount target file system having been fsck'ed by actually booting it up. I took dumpe2fs file here: fiesty-3rd-dumpe2fs-dev-sdb2.txt.

To summarize, I have 4 dumpe2fs output files and 3 ls -lt output files.

Comparing the output of the first fiesty dumpe2fs output with the dapper dumpe2fs reveals the following differences:
1) diff fiesty-dumpe2fs.txt dapper-dumpe2fs.txt
Interesting the the UUIDs are different, I do not know if this is significan:
< Filesystem UUID: b3b59a60-f53d-11d5-8b5e-b53bf555251f
---
> Filesystem UUID: 994715d4-eb69-4cb3-85af-474c958dc0c9
Very interesting difference in Filesystem features:
< Filesystem features: has_journal filetype needs_recovery sparse_super
---
> Filesystem features: has_journal ext_attr filetype sparse_super
Interesting diffences in Inode, Block, Reserved block, Free blocks and Free inode counts:
< Inode count: 9703584
< Block count: 9703260
< Reserved block count: 485163
< Free blocks: 8442791
< Free inodes: 9480945
---
> Inode count: 9568256
> Block count: 19127390
> Reserved block count: 956369
> Free blocks: 13963515
> Free inodes: 9247306
Very interesting Mount count and Maximum mount count differnce:
< Inodes per group: 32672
< Inode blocks per group: 1021
< Last mount time: Fri Sep 7 05:49:13 2007
< Last write time: Fri Sep 7 05:49:13 2007
< Mount count: 706
< Maximum mount count: -1
< Last checked: Thu Dec 20 11:35:43 2001
< Check interval: 0 (<none>)
---
> Inodes per group: 16384
> Inode blocks per group: 512
> Filesystem created: Wed Mar 30 21:58:55 2005
> Last mount time: Fri Sep 7 07:25:07 2007
> Last write time: Fri Sep 7 07:26:47 2007
> Mount count: 91
> Maximum mount count: 30
> Last checked: Wed Aug 15 10:29:48 2007
> Check interval: 15552000 (6 months)
> Next check after: Mon Feb 11 10:29:48 2008
The last difference is that Fiesty records a Journal size, Dapper not:
< Journal size: 32M
<

It is very clear that Fiesty reads the UUID differently than Dapper, and that the problem (as you will see from later dumpe2fs comparisons) occurs when Fiesty does not indicate an ext_attr Filesystem feature. Perhaps that has something to do with why it records "needs recovery" as a Filesystem feature?

After Dapper had been run and Fiest did not work the next attempt before the FC3 hard drive was booted up, the needs_recovery Filesystem feature did not appear, but then again, neither did the ext_attr which Dapper's dumpe2fs indicated.

Comparing the 2nd and 3rd fiesty dumpe2fs outputs:
< Filesystem features: has_journal filetype sparse_super
---
> Filesystem features: has_journal ext_attr filetype sparse_super
Hooray, Fiesty now can conclude that the FC3 Linux file sytem has an ext_attr Filesystem feature!!!
< Inodes per group: 32672
< Inode blocks per group: 1021
< Last mount time: Fri Sep 7 10:31:35 2007
< Last write time: Fri Sep 7 10:33:06 2007
< Mount count: 708
< Maximum mount count: -1
< Last checked: Thu Dec 20 11:35:43 2001
< Check interval: 0 (<none>)
---
> Inodes per group: 16384
> Inode blocks per group: 512
> Filesystem created: Wed Mar 30 21:58:55 2005
> Last mount time: Fri Sep 7 15:09:03 2007
> Last write time: Fri Sep 7 15:13:11 2007
> Mount count: 1
> Maximum mount count: 30
> Last checked: Fri Sep 7 15:09:03 2007
> Check interval: 15552000 (6 months)
> Next check after: Wed Mar 5 15:09:03 2008
Now, the Maximum mount count is corrected to 30 after the fsck on the Linux FC3 filesystem by booting it up.

Apparently, detection of the ext_attr Filesystem feature is significant and related to why Fiesty does not apply the journal when the problem occurs.

I did not experience an unclean unmount or power off without shutdown which usually incurs the needs_recovery. However, there were a number of system messages that came up too fast to read when I did shutdown last night - if only there was a way to save them with the Live CD environment - they must have precipitated this event.

Since I had a clean unmount of the Linux hard drive prior to shutdown, the shutdown messages and whatever caused them probably did not have anything to do with what causes the Fiesty mount command to fail to apply the journal.

In a subsequent failure after only about 6-7 mounts, the failure again happened, however, this time the needs_recovery notice of the Filesystem features did not appear, but the ext_attr was again absent. Additionally, the mount count was somethine like 711, and the Maximum mount count was -1. Significantly, Dapper again had no problems mounting the Linux hard drive after this new mount failure to apply journal event occurence.

I suspect that between Dapper>Edgy>Fiesty there were changes to the mount command source code which raises the question of whether the problem will be carried forward to Ubuntu Gutsy Gibbon 7.10 in October 2007.

-- Tom

Last edited by lotuseclat79; 09-10-2007 at 07:48 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Bind9: NDC command failed : rndc: connect failed: connection refused Boudewijn Linux - Networking 19 01-02-2014 07:19 AM
bash script to apply sed command only to a specific text area mauran Programming 6 07-13-2007 04:38 PM
"apply journal on ext3 filesystem" - how? kpachopoulos Linux - General 1 02-10-2006 06:56 AM
automount: mount(generic): failed to mount (null) (type iso9660) on /mnt/media/ vasudevadas Slackware 5 10-17-2005 03:05 PM
portage patch failed to apply doralsoral Linux - Software 2 05-12-2005 03:27 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 05:17 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration