asp@COS.COM (Andrew S. Partan) (10/16/87)
I know that at one point, one could not dump a file system, make a new
smaller file system, and restore that dump into that smaller file
system. Is this still so? My restore(8) man page says something about
'running as a user process' so that (I assume) it does not muck with
the raw disk but just creates files like any 'normal' user process
might. This leads me to believe that I could do a restore into a
smaller partition (assuming that there is sufficient disk space to hold
all of the files). [I really do not want to have to tar files out &
back in again.]
We are running Sun OS 3.4 (based on BSD 4.2, with some BSD 4.3 and
System V stuff). I think that I am using BSD 4.2's dump/restore.
I have one file system (partition) about 70% full with about 40 Meg
left over. I need to make another partition larger (and thus make the
first one smaller). If I make the first partition smaller by about 20
Meg, its files will still fit onto it.
Can I dump the partition, make it smaller, and restore my dump onto
that (smaller) partition?
Extract from restore(8):
.... Because restore runs in user mode, it has no control over
inode allocation; this means that restore repositions the
files, although it does not change their contents. ...
Please reply by mail, I will summarize to the newsgroup.
Thanks in advance for any help.
--
--asp (Andrew Partan @ Corporation for Open Systems)
-- asp@cos.com
-- {uunet, sundc, decuac, hqda-ai, hadron}!cos!aspasp@COS.COM (Andrew S. Partan) (10/21/87)
In article <482@cos.COM>, *I* wrote: > Can I dump [a] file system, make it smaller, and restore my dump onto > that (smaller) file system? The answer is: Yes it is possible (at least for BSD 4.2 or later systems). Cavaets: You have to make sure that is enough space in the new file system for all of the files in the old file system, PLUS space for the restoresymtable. Note: You must do a level 0 dump after restoring the partition. I think that Guy Harris said it best: One problem is that "restore" has a symbol table that it keeps around in the file system it's working on; it does this so that if you restore a full dump and then an incremental dump, it will not only know that some files *changed* or were *added* between the full and incremental dumps, it will also know that some files were *deleted* between the dumps, and can *remove* those files as part of restoring the incremental dump. Unfortunately, this symbol table can be very big, which means you need enough space on the partition for all the files *and* for the symbol table. (The astute reader will note that this can make it impossible to restore a full dump of a partition back onto that partition after re-"newfs"ing that partition.) Unfortunately, there is no way to say "put that thing somewhere else!". Thanks for answers from: David S. Hayes <merlin@hqda-ai.UUCP> Kyle Jones <kyle@xanth.cs.odu.edu> Guy Harris <guy@sun.com> Chris Torek <chris@mimsy.umd.edu> James P. Kiely <kiely@lownlab.harvard.edu> Dave Marquardt <dave@rosevax.Rosemount.COM> Keith DeJager <uunet!rutgers!EDDIE.MIT.EDU!gatech!sunatl!suntri!dj> Roger Rose <uunet!EDDIE.MIT.EDU!gatech!stcvax!rlr> Thanks again for help from the net. -- --asp (Andrew Partan @ Corporation for Open Systems) -- asp@cos.com -- {uunet, sundc, decuac, hqda-ai, hadron}!cos!asp
rkd@cci632.UUCP (Ray Downes) (10/22/87)
On our BSD4.[2-3] systems as well as some SYSV (w/BSD4.N guts), I've used dump piped to restore with a dirty twist: dump 0f - /dev/raw_oldone | (cd mounted_newone; restore if -) ^ This slow but sure (but faster than 9-track tape) method allowed splitting of some rather hefty filesystems (assumed same system (or usable "network"), onto "newfs"ed smaller partitions (via N passes). Seemed to work fine, dirty as it is .... -- Ray Downes, CCI, (716) 482-5000 rutgers!rochester!cci632!rkd
acheng@uiucdcsb.cs.uiuc.edu (10/23/87)
>/* Written 1:18 pm Oct 21, 1987 by asp@COS.COM in uiucdcsb:comp.unix.questions */ >I think that Guy Harris said it best: > > One problem is that "restore" has a symbol table that it keeps > around in the file system it's working on;... > > Unfortunately, this symbol table can be very big, which means > you need enough space on the partition for all the files *and* > for the symbol table. (The astute reader will note that this > can make it impossible to restore a full dump of a partition > back onto that partition after re-"newfs"ing that partition.) > Unfortunately, there is no way to say "put that thing somewhere > else!". If Guy Harris really said that, do I have something to surprise him. Use a symbolic pointer to bypass it. E.g. if you are restoring a full /a: cd /a ln -s /tmp/restoresymtable restoresymtable # make sure /tmp/restoresymtable does not exist or is 0 byte. restore r The restoresymtable grows in /tmp, not /a. (This works in my 4.3BSD VAX system and I imagine it will in others) If your old system was absolutely full that not even a symbolic pointer could fit, remove lost+found after restore has started. It is usually empty. But this I have not tested. ---------------------------------------------------------------------- Albert Cheng acheng@a.cs.uiuc.edu (ARPAnet or CSNET) uiucdcs!acheng(USENET) Dept. of Computer Science, Univ. of Illinois-Urbana, Rm. 240, 1304 W. Springfield, Urbana, IL 61801, USA. %%% The above is my opinion STOP %%%
chris@mimsy.UUCP (Chris Torek) (10/25/87)
In article <484@cos.COM> asp@COS.COM (Andrew S. Partan) writes: >... Guy Harris [mentioned] ... "restore" has a symbol table that it keeps >around in the file system it's working on; ... this symbol table can be >very big ... [but] there is no way to say "put that thing somewhere >else!". Ah, but there is such a way. I had to do it once; I know it works: First mount the file system to be restored: # mount /dev/hp3a /a # cd /a Now mount something with enough room for "restoresymtable": # mount /dev/hp4a /tmp Finally, make a symlink from ./restoresymtable to a file in that second file system: # ln -s /tmp/restoresymtable restoresymtable # restore rf ... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
rbj@icst-cmr.arpa (Root Boy Jim) (12/29/87)
In article <484@cos.COM> asp@COS.COM (Andrew S. Partan) writes: >... Guy Harris [mentioned] ... "restore" has a symbol table that it keeps >around in the file system it's working on; ... this symbol table can be >very big ... [but] there is no way to say "put that thing somewhere >else!". Ah, but there is such a way. I had to do it once; I know it works: At *least* one. First mount the file system to be restored: # mount /dev/hp3a /a # cd /a Now mount something with enough room for "restoresymtable": # mount /dev/hp4a /tmp Finally, make a symlink from ./restoresymtable to a file in that second file system: # ln -s /tmp/restoresymtable restoresymtable # restore rf ... In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris restore x creates *no* symbol table file. And no, I do not believe in incremental restores. I do restores into separate directorys and move the files. Deletions are easy enuf to do. Another thing you can do is start your restore with the verbose option, capturing the list of restored files. Suspend the restore when the file system starts to fill, and point compress at the list of files already restored. When space reappears, resume the restore. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 Well, O.K. I'll compromise with my principles because of EXISTENTIAL DESPAIR!