[OpenAFS-devel] RE: Really slow vos dumps to local disks

[Neulinger, Nathan R.]

troot-srvtst03(76)> time vos dump test1 -time 0 -file /dev/null -server
srvtst03 -partition /vicepb -localauth
0.970u 0.870s 0:24.49 7.5%      0+0k 0+0io 199pf+0w
troot-srvtst03(77)> time /tmp/volinfo -part /vicepb -volumeid 536870915
-saveinodes > /dev/null
0.400u 1.170s 0:01.58 99.3%     0+0k 0+0io 124pf+0w

That's pretty damn clear to me. (note - the volinfo is kindof broke, but it
does retrieve all the data off the disk and write it - in this case the
volinfo open() has been changed to open /dev/null to keep things similar
since I only have one disk in the box at the moment.)

-- Nathan

> -----Original Message-----
> From: Neulinger, Nathan R. [mailto:nneul@umr.edu]
> Sent: Friday, March 16, 2001 10:03 AM
> To: 'Ken Hornstein'
> Cc: 'openafs-devel@openafs.org'
> Subject: [OpenAFS-devel] RE: Really slow vos dumps to local disks
> 
> 
> Turns out from looking at the source to volinfo, it looks 
> like most of it is
> already implemented (at least for the file inodes - they just 
> get dumped out
> to files, but that is simple enough to change to writing out 
> as a vos dump
> type file), but it core dumps for me. I'll be taking a closer 
> look at it,
> and seeing if I can get it at least to where it will 
> successfully dump out a
> full volume.
> 
> If dumping out all the files on a volume using volinfo is 
> significantly
> faster than the same operation using 'vos dump' then it'd likely be
> worthwhile adding dump output support to volinfo. (In fact, might be
> worthwhile to just take volinfo and rename it 'volutil', clean up the
> output, and make it the 'server side equivalent of vos'.
> 
> -- Nathan
> 
> > -----Original Message-----
> > From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil]
> > Sent: Thursday, March 15, 2001 3:26 PM
> > To: Neulinger, Nathan R.
> > Subject: Re: Really slow vos dumps to local disks 
> > 
> > 
> > >Do you think it'd be worth going to the trouble of making a
> > >server-side-vos-dump command that bypassed RX and read the 
> > volume data
> > >directly using the same interface as the volserver uses? If 
> > it's potentially
> > >will be a lot faster, it's worth my time to figure out 
> > enough to write it...
> > 
> > "yes".  The thing is, I don't think there's a reasonable 
> API inside of
> > there, so you'd have to essentially re-do all of it yourself 
> > (which isn't
> > all that much; it's hairy, but I think it's reasonable to 
> do).  You'd
> > want to talk to the FSYNC port on the fileserver to tell it 
> to let go
> > of the volume you're dumping, of course.
> > 
> > --Ken
> > 
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo.cgi/openafs-devel
>