Subject: Re: newfs/newlfs/newfs_msdos (was Re: Some LFS troubles)
To: Brian C. Grayson <bgrayson@marvin.ece.utexas.edu>
From: Luke Mewburn <lukem@goanna.cs.rmit.edu.au>
List: tech-kern
Date: 03/14/1999 09:57:01
"Brian C. Grayson" writes:
> On Thu, Mar 11, 1999 at 05:30:42PM -0800, Chris G. Demetriou wrote:
> > "Kevin P. Neal" <kpneal@pobox.com> writes:
> > > Has anyone thought about {dump,restore}_{ffs,lfs,etc} and so on?
> > 
> > not really, but they probably should.
> 
>   Well, I did a few days ago:  See my message from 03/03
> on "dump and nodump flag".  My point was, if we allowed dump
> to use a generic filesystem traversal framework (like fts, but
> also for unmounted filesystems) and did a clean job of it, then
> it would be trivial to write dump for other filesystem types --
> you'd just have to change the walker, and maybe some bits of the
> dumped information, depending on the fs.
> 
>   I would like to write such a dump, and see if the reduction
> to one less pass with a traversal makes up for the lack of
> locality in the inode reads.

The main problem with this is that how do you allow people in group
operator to dump the disk in this situation? Currently they have
read access on the disk device.

Note that subdir dump(8)ing already uses fts(3) and also has this
problem (operators can't subdir dump directories they can't read);
fixing this would have required hacking a chunk of the kernel's
inode parsing code into dump(8), and I wasn't prepared to do that
when I first hacked in subdir dumping ;-)