[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: tune2fs -j on mounted FS



Sean Neakums <sneakums zork net> writes:

> Sean Neakums <sneakums zork net> writes:
>
>> "Theodore Ts'o" <tytso mit edu> writes:
>>
>>> On Wed, Oct 29, 2003 at 07:52:23PM +0000, Sean Neakums wrote:
>>>> Just now I ran tune2fs -j on the root filesystem of a box running
>>>> 2.6.0-test8.  Then I edited /etc/fstab and changed the FS type to from
>>>> ext2 to ext3, saved the file, and invoked vim on the file again.  A
>>>> few moments after this, the box hung.  Unfortunately X was running at
>>>> the time, and so I don't have any messages to cite.
>>>> 
>>>> Is this a known problem?
>>>
>>> This is the first time anyone has reported anything like this.  All
>>> tune2fs -j does on a mounted filesystem is to create a normal file
>>> (which is used for the journal), mark it immutable, and the modify the
>>> superblock to set the has_journal flag and set the journal inode
>>> number.   None of this should cause a kernel hang.  
>>
>> I was rather taken aback myself.
>>
>>> What version of e2fsprogs/tune2fs were you using?
>>
>> tune2fs -V reports "tune2fs 1.35-WIP (21-Aug-2003)"
>>
>> Obtained from Debian package e2fsprogs version 1.34+1.35-WIP-2003.08.21-3.
>
> I tried reproducing this on my laptop, which also had an ext2 root and
> was also running 2.6.0-test8.  I ran the tune2fs -j (same version and
> source as above) and updated /etc/fstab as before.  Nothing seemed to
> be breaking, so I went ahead and built 2.6.0-test9 in my homedir,
> which is on a separate volume (/ and /boot are regular partitions;
> /home, /usr and /var are lvm2 volumes.  The other box has a similar
> configuration.).  When I ran make modules_install, messages of the
> following form began streaming on the console:
>
> block=X, b_blocknr=X
> b_state=0x00000000(?), b_size=1024
>
> The Xes are numbers that I couldn't make out due to the messages
> streaming so fast.  b_blocknr seemed to be changing, although I don't
> know if there were repeats.  I'm fairly sure but not certain that
> b_state was 0x00000000.  The filesystem itself has 1024-byte blocks.
>
> I had a quick grep around, and this message seems to come from
> fs/buffer.c:__find_get_block_slow().

I inserted a dump_stack and panic after the printk, removed the
journal from the root FS in the usual manner, recreated as above, and
triggered this again.  Below is the call trace, sans addresses and
offsets; the full trace is at http://zork.net/~sneakums/trace.png
(44302 byte PNG image).  The message that __find_get_block_slow prints
was scrolled up by some network-related messages as I took the
picture, but b_state was 0x00000000 and b_size 1024.

__find_get_block_slow
__find_get_block
__getblk
__bread
read_block_bitmap
ext2_free_blocks
ext2_truncate
mark_buffer_dirty
ext2_update_inode
ext2_delete_inode
ext2_delete_inode
generic_delete_inode
vfs_unlink
ext2_put_inode
iput
sys_unlink
syscall_call




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]