On Nov 18, 2001 21:42 +1300, John Huttley wrote:> If I made a cpio backup of an ext3 fs. Then created a new fs and
> restored everything including the .journal file,
>
> What would happen??
Well, it depends on several factors:
1) Under normal circumstances, you would have a hidden journal file
(especially with the newer e2fsck which moves the journal to be
hidden), so you would just have a big useless file called .journal
in your filesystem.
2) If you don't have a hidden .journal, then tune2fs will normally
set the .journal file so it is immutable (i.e. it cannot be
changed, even by root), so you would not be able to overwrite it.
3) If you created your own journal (back in the old days when you had
to do that), and it wasn't set immutable, then you would overwrite
the .journal file. Unless you crash at just that time, nothing
would happen, and after a while the journal would be re-written
with valid data.
4) If you crashed during #3, then one of two possible things would happen,
either the journal superblock was still the one you restored (that
matches the transaction sequence numbers that you also restored to the
journal) in which case you would badly corrupt your filesystem when the
journal is restored. The other alternative is that the journal superblock
had been re-written (with the new transaction number), in which case all
of the restored transactions would be discarded because their numbers
didn't match what the superblock said (unless you were _really_ unlucky).
Note that doing strange things like #3 _may_ cause the ext3 code to
"assert"
an error because it is outside the scope of normal operations (I don't know
if that would actually happen, but it might). That _might_ precipitate #4
happening.
So, the moral of the story is "don't do that". One thing that the
ext3
and e2fsck code could do to combat utter foul-ups like this to compare
the filesystem and journal UUIDs to ensure they match. We currently
don't have a good "record" on keeping these two in sync (old code
didn't
set the journal UUID, and new e2fsck clears it by mistake), but it could
be done in the future as a security precaution (probably not worth it,
given the lengths you have to go through to break things, but you never
know what is possible).
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/