> I would suggest that rather than making the single dump program smart enough
> to handle all different filesystem types, you follow the lead of fsck and
> make a generic "dump" front-end which determines the filesystem type and then
> calls the apropriate dump.<fstype> back-end. This would allow you to have
> dump.ext2, dump.ufs, etc, without making a single dump program so complex.
This is of course an interesting idea, but: fsck backends are really
different between them, they do not share any code... Dump backends would
be 90% identical, so I'm not so sure that adding new filesystem types would
complicate the common code...
> Actually, I was even able to restore an AIX mksysb tape (essentially a by-file
> dump) on Linux using dump 0.4b4, so I think it very important not to change
> the on-tape dump format - it might even be a POSIX standard, just like tar.
Keeping compatibility is of course very important.
> Now if only there was the ability to have the system boot from a Linux dump
> tape, and re-create all of the partitions and filesystems ala AIX during
> the restore, I'd be a happy camper...
I'm not sure if Linux can boot on a tape drive, and how to deal with this.
But it would surely be a good idea to implement this. If only I had the
time :)...
Stelian.
--
/\
/ \ Stelian Pop
/ DS \ Email: pop@cybercable.fr
\____/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/