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

Re: Visible /.journal

On Thu, Dec 27, 2001 at 11:57:03PM -0700, Andreas Dilger wrote:
> Hmm, what would be involved for the kernel code?  If we caught it between
> journal recovery, but before the journal was busy, it would be a matter of:
> 1) read the ext2_inode data into memory from current journal inode number
> 2) write the ext2_inode data into reserved inode #8, sync write
> 3) change the journal inode number in the superblock, sync write
> 4) set dtime for the old journal inode, clear immutable attribute, clear
>    bit in inode bitmap
> 5) take a guess that .journal is in the root directory and remove it, or
>    mark the fs dirty for e2fsck to clean up on the next reboot if we can't
>    find it there (it should just disappear if the inode is empty and it is
>    marked unused in the inode bitmap and has a dtime).
> This should be pretty safe if the ordering is done correctly.

You *really* don't want to leave the filesystem in an inconsistent
state at step (5), since the inode that was formally .journal could
get reallocated, and then if the user tries to delete .journal, blocks
that are in use would get marked as freed, at which point they could
be double-allocated.....   Bad, bad, bad, ju-ju.   

So you need to search for an entry with the same inode number as the
journal inode as reported in the superblock entry first, and if you
can't find it, abort the whole process of trying to move the journal
then and there.   Still, it's not *that* much work, but it is extra stuff in the clutter.

> Sadly, the ext3 code opens the journal of a filesystem even when it is a
> read-only mount, rather than opening it only when the fs is mounted
> read-write, so it would not be possible to restrict this to when the fs is
> mounted read-only.  That has caused me some headaches in the past as well.
> Maybe it is time that we change ext3 so that we still do a journal
> recovery for a read-only mount (on rw media), but then close the journal
> again until we do a real read-write mount?  That is not a requirement for
> in-kernel journal moving, but then we are messing with what _should_ be a
> read-only fs.

That might be the simplest fix, yes.  At that point, it would be safe
to do the .journal manipulation in user space before the root
filesystem is remounted read-write.  The one headache this leaves
userspace with is needing to determine whether or not it's running a
kernel which releases the journal on read-only mounts so that it's
safe to manipulate the .journal file while the root is mounted

							- Ted

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