root@telmail.UUCP (Super user) (08/31/88)
On DOS PC's there are several programs to defragment the disk (i.e. make files take up contiguous sectors/tracks and move then to the 'beginning' of the disk). Such a defragmentation option is not available on SCO XENIX/386. (Is it available on ANY UNIX?) Can fragmentation cause severe performance degradation on SCO XENIX? I ask this specifically for SCO XENIX because in the (kernel) 'configure' program there is an entry called 'disk block sorting'. Does that have anything to do with fragmentation? And if so, is it effective enough to replace a backup/delete/restore procedure one in a while? (If not, what DOES the 'disk block sorting' do?) Richard (...!mcvax!neabbs!richard)
john@jetson.UPMA.MD.US (John Owens) (09/03/88)
In article <116@telmail.UUCP>, root@telmail.UUCP (Super user) writes: > Such a defragmentation option is not available on SCO XENIX/386. If you want to reorder your filesystem, dump, mkfs, and restore. > Can fragmentation cause severe performance degradation on SCO XENIX? I suppose it could impact performance if it got really bad; it all depends on the seek time of your drive and the number of buffers you have allocated. > I ask this specifically for SCO XENIX because in the (kernel) 'configure' > program there is an entry called 'disk block sorting'. Does that have > anything to do with fragmentation? No. If this is the same disk block sorting in "real" UNIX, it sorts pending I/O requests to do them in an optimal order. In other words, if there were pending writes for blocks on cylinders 482, 12, and 216, and the last I/O was at cylinder 20, it would do the writes in the order 12, 216, then 482 (hopefully). -- John Owens john@jetson.UPMA.MD.US uunet!jetson!john +1 301 249 6000 john%jetson.uucp@uunet.uu.net
debra@alice.UUCP (Paul De Bra) (09/12/88)
In article <116@telmail.UUCP> Richard writes: >>Can fragmentation cause severe performance degradation on SCO XENIX? I did some testing: create a small c-program which opens 2 files and writes blocks (1k or so) to each of them, alternating between the 2 files. Create a few megabytes of data this way, then delete the files. On some particular system I measured about 10 seconds per megabyte with a new file system. Repeat this process for a few hours (just a few hours!!!!), the time quickly exceeded half a minute per megabyte. So YES performance degrades. Solutions? 1) Use separate file systems for heavily used directory subtrees like /tmp and /usr/spool. 2) If you know how to do it and have lots of memory, use a ramdisk for /tmp, but do not use SCO's ramdisk. A quick hack is all it takes to write your own ramdisk driver which is 3 times faster. A plain vanilla 286 AT needs only 3 to 4 seconds per megabyte on a (Xenix) ramdisk. 3) Run fsck -S frequently on heavily used file systems, to rearrange the free list. (don't do this while a file system is mounted!) 4) If you really want your baby to fly: have /etc/rc copy your most popular programs (C-compiler and its passes for instance, and vi or emacs...) to a ramdisk. You'd be amazed about the performance gain. (don't forget to include the directory you mount the ramdisk on in your PATH, before /bin and /usr/bin). This degradation is not typical a Xenix problem: all V7 file systems suffer from this problem. Getting faster disks and using large buffer pools doesn't help a bit. The overall performance gets better, but the difference between a new and an old file system remains. I don't know about the degradation in uport Unix. I did run my test once on a 286 machine, and on a new file system the test took already longer than on an old Xenix file system... Paul.
richard@neabbs.UUCP (RICHARD RONTELTAP) (09/13/88)
Thanx, I think fsck -S was the tip I was waiting for. But... Can you tell me what this actually does to the disk? Does it move files around te get the free spaces on the 'end' of the disk? Does it also defragment files? (would it make the files in the alternate-write-test consecutive again?) And lastly, can I do it on the root (booting) filesystem on the HD, when I boot from a floppy? Many thanks in advance, Richard (...!mcvax!neabbs!richard)
debra@alice.UUCP (Paul De Bra) (09/15/88)
Richard Ronteltap is a bit overly enthousiastic about fsck -S as the tool for avoiding fragmentation. What fsck -S does is rearrange the list of FREE BLOCKS in such a way that newly create files will be less scattered over the whole disk. fsck -S does NOTHING to existing files. You can do it safely, only on unmounted file systems. To fsck -S root: first go into single user mode (kill -1 1, and then type root password when asked to). Then (umount all other file systems and) sync; sync the disk. Then run fsck -S on the root file system. Then press the hardware reset button on the computer or power-cycle. Do NOT use /etc/haltsys in this case, because that will write the old in core superblock onto the newer superblock created by fsck. (When rebooting, the root file system will be checked again.) fsck -S does not turn an old file system into a new one. But if one starts with a new file system and goes through this procedure once every day or so, these few minutes or seconds will slow down the fragmentation considerably. We started this routine a few years ago, on a rather busy machine, and after three months the file systems were still in good shape, whereas before the Unix system would become noticeably slower after about a month or so. The Berkeley fast file system and the 9-th edition Unix 4k file system perform "fsck -S"-like actions all the time, and don't degrade as quickly. Hopefully future releases of Xenix will include a similar approach. Paul.