rogerj@batcomputer.tn.cornell.edu (Roger Jagoda) (02/23/90)
Folks, I know this can't be too hard, but NO ONE in Unix-land seems to know what I'm talking about. I'm a converted (truly!) PC guru used to working with Novell Lans and 386s. Now I work on Unix workstations. Under trusty old DOS, I sometimes had problems with disk fragmentations. In other words, files became scattered all over the disk and head performance suffered on seeks of the random data. Now, the same problem exists under UNIX, but with DOS systems I have my choice of 6 or 7 GOOD disk managers/defragmentors. Under UNIX, there doesn't seem to be ANYTHING (or if there is could someone point me towards it). Performance still sufferes but you'd think the UNIX world would have access to the same tools as the DOS (Dumb OS?) world...wouldn't you? Another somewhat silly question. We're using dump for our backups. I ahve heard of BRU and CTAR. Has anyone used these and found them satisfactory? Their priced within our range, I just wanted to get some feedback before buying. BTW, what does "dd" do so well that people tell me I should use that for tape backup instead? The man page clearly shows it for a file conversion utility, such as EBSIDIC to ASCII. Why would I want to use this in tape backups? Just asking...tar seems good enough, although, again, under the DOS world, I have my choice of several GOOD programs for disk management/compression-backup. I just can't under- stand why the UNIX world has such a dearth of similar software..I guess everyone just likes to write their own! Seems fun enough! Thanks in advance! --Roger Jagoda --Cornell University --FQOJ@CORNELLA.CIT.CORNELL.EDU
gwyn@smoke.BRL.MIL (Doug Gwyn) (02/23/90)
In article <9782@batcomputer.tn.cornell.edu> rogerj@tcgould.tn.cornell.edu (Roger Jagoda) writes:
-Now, the same problem exists under UNIX, but with
-DOS systems I have my choice of 6 or 7 GOOD disk managers/defragmentors.
-Under UNIX, there doesn't seem to be ANYTHING ...
dump; mkfs; restore
(or equivalent)
-BTW, what does "dd" do so well that people
-tell me I should use that for tape backup instead? The man page clearly
-shows it for a file conversion utility, such as EBSIDIC to ASCII. Why
-would I want to use this in tape backups?
"dd" is not an archiver at all! However, it does give you control
over I/O blocking, which is significant for magtape.steve@pmday_2.Dayton.NCR.COM (Steve Bridges) (02/24/90)
When our file systems get really fragmented, we backup up the file system with cpio to an 8mm tape drive (it can hold up to 2GB) with cpio using the following commands, e.g. cd /usr/acct find . -print | cpio -ocvB > /dev/rmt/64yy Then after the backup is done cd /usr/acct (THIS IS A MOST IMPORTANT STEP) rm -r * cpio -idmuvcB < /dev/rmt/64yy This will put it all back on disk, unfragemented. We use dd quite a lot. Most of our use of dd is to byte-swap tapes where the utility that created them stores bytes on the opposite order of what we expecte them to be in. -- Steve Bridges | NCR - USDPG Product Marketing and Support OLS Steve.Bridges@Dayton.NCR.COM | Phone:(513)-445-4182 622-4182 (Voice Plus) ..!ncrlnk!usglnk!pmday_2!steve | AOPA #916233 ..!uunet!ncrlnk!usglnk!pmday_2!steve| PP-ASEL, AMEL
terry@jgaltstl.UUCP (terry linhardt) (02/27/90)
In article <876@pmday_2.Dayton.NCR.COM>, steve@pmday_2.Dayton.NCR.COM (Steve Bridges) writes: | When our file systems get really fragmented, we backup up the file | system with cpio to an 8mm tape drive (it can hold up to 2GB) with | cpio using the following commands, e.g. | | cd /usr/acct | find . -print | cpio -ocvB > /dev/rmt/64yy | | Then after the backup is done | | cd /usr/acct (THIS IS A MOST IMPORTANT STEP) | rm -r * | cpio -idmuvcB < /dev/rmt/64yy | | This will put it all back on disk, unfragemented. Actually, I don't believe this is necessarily correct. The method in which Unix (at least System V) reuses blocks is on a 'last one used, first one reused' basis. Therefore, when the files are restored from tape, they may *still* be fragmented. In the above example, if /usr/acct is an entire file system, one could remake their file system with mkfs and then restore the files. As an alternative, one could do an fsck on an unmounted file system with the -s option and then restore the files. -- |---------------------------------------------------------------------| | Terry Linhardt The Lafayette Group uunet!jgaltstl!terry | |---------------------------------------------------------------------|
les@chinet.chi.il.us (Leslie Mikesell) (03/01/90)
In article <12217@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >>Now, the same problem exists under UNIX, but with >>DOS systems I have my choice of 6 or 7 GOOD disk managers/defragmentors. >>Under UNIX, there doesn't seem to be ANYTHING ... >dump; mkfs; restore >(or equivalent) What is the SysV equivalent? How do you do it to the root (possibly only) filesystem. Is it save to restore it back to a different disk drive (I'm thinking about the '386 style /etc/partitions file here)? Is there any way to use dcopy without having a spare identical partition (i.e over RFS or to tape, then back)? Les Mikesell les@chinet.chi.il.us
cpcahil@virtech.uucp (Conor P. Cahill) (03/02/90)
In article <1990Mar1.062015.13739@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >What is the SysV equivalent? How do you do it to the root (possibly only) >filesystem. Is it save to restore it back to a different disk drive (I'm >thinking about the '386 style /etc/partitions file here)? Is there any >way to use dcopy without having a spare identical partition (i.e over >RFS or to tape, then back)? For any system, be it system V or BSD, the way to handle this is to make root very small so that it only contains required directories (/bin, /etc, /lib) and place the rest of the stuff onto other file systems. This makes your root directory fairly static and therefore reduces, if not elimates, any fragmentation. Another good side effect is that the smaller and more static that the root device is, the less likely that you will have file system problems on that partition. If you still need to defragment root, you must make a backup copy, reboot the system on another device (floppy for your 386 example) from that device, mkfs, restore, shutdown and reboot. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
les@chinet.chi.il.us (Leslie Mikesell) (03/14/90)
In article <1990Mar2.134004.23530@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >For any system, be it system V or BSD, the way to handle this is to make >root very small so that it only contains required directories (/bin, /etc, >/lib) and place the rest of the stuff onto other file systems. I used to do that but quit after a release upgrade wouldn't fit. This was on 3B2's, somewhere around the transition from SysVr2 to SysVr3r. Rebuilding the machines (slow 720K floppies...) took several days each. I suspect the same sort of thing will happen when SysVr4 comes around but at least we have tape drives or network links on everything now. >This makes your root directory fairly static and therefore reduces, if not >elimates, any fragmentation. Another good side effect is that the smaller >and more static that the root device is, the less likely that you >will have file system problems on that partition. It also means that you have to mount /tmp from another partition if you want any space there, and you can't share the space between /tmp and /usr/tmp, and that anything that uses workspace in /tmp has to copy the finished file back instead of being able to link it into the /usr filesystem. >If you still need to defragment root, you must make a backup copy, reboot >the system on another device (floppy for your 386 example) from that >device, mkfs, restore, shutdown and reboot. That's reasonable, but if your new filesystem isn't an exact duplicate of the old one, you would have to adjust /etc/partitions (anything else??). Is it possible to bring up RFS when booting from a floppy? Les Mikesell les@chinet.chi.il.us