emmo@moncam.co.uk (Dave Emmerson) (01/15/90)
Several postings in recent weeks have prompted me to post this. As I've only skimmed the literature on DOS file structures, I acknowledge that my understanding of this may be incorrect. Feel free to enlighten me.. Whenever I've formatted a hard disk I always begin by building the directory trees first, (that is, with NO FILES IN THEM). I have a small batch file on floppy which does most of this automatically. Another small programme creates this batch file if I want to copy/rebuild an existing disk. Then the most frequently used files are copied into their respective directories, finally the remainder are installed. The object of this is simply to keep the most often read tracks closest to track 0, this should reduce the amount of stepping needed to access any particular file more often than not. Even if the speed gain is negligable, the saving in wear and tear on the stepper motor is worth this small effort. I've no idea what sort of improvement this yields, but I suspect it's worthwhile on my system at least, since the hard disk is one of those 'intelligent' ones which self-park if you don't access it for half a minute or so, and re-seeks track 0 next time it's accessed. Anyone disagree? Dave E.
wayne@dsndata.uucp (Wayne Schlitt) (01/16/90)
In article <361@marvin.moncam.co.uk> emmo@moncam.co.uk (Dave Emmerson) writes: > [ ... ] > > The object of this is simply to keep the most often read tracks closest > to track 0, this should reduce the amount of stepping needed to access > any particular file more often than not. Even if the speed gain is > negligable, the saving in wear and tear on the stepper motor is worth > this small effort. actually on the mainframe systems i used to administer, we tried to keep the most used/important files in the center (middle track) of the disk. that keeps the max seek down to 1/2 of the disc, and the average seek to 1/4 of the disc. if you put the important stuff on either end you will have a max seek of the entire disc and an average of 1/2. this, of course, assumes that your disc is basically full, or with the files distributed evenly across the disk. i also dont remember were exactly the fat table is on msdos and i dont know how often msdos read/writes it. i suppose if the fat table is at the front of the disk and you dont have any disk caching, then yes, the front of the disc is where you want to put important stuff. -wayne
burton@mitisft.Convergent.COM (Philip Burton) (01/17/90)
In article <361@marvin.moncam.co.uk> emmo@moncam.co.uk (Dave Emmerson) writes: >Several postings in recent weeks have prompted me to post this. > >Whenever I've formatted a hard disk I always begin by building the directory >trees first, (that is, with NO FILES IN THEM). I have a small batch file >on floppy which does most of this automatically. Another small programme >creates this batch file if I want to copy/rebuild an existing disk. Any chance you could post these small batch files. They sound genuinely useful. > >Dave E. <space for the stupid news poster>
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (01/18/90)
In article <WAYNE.90Jan15193304@dsndata.uucp> wayne@dsndata.uucp (Wayne Schlitt) writes:
[ ... stuff about keeping common files in the middle of the disk
on a mainframe ...]
$this, of course, assumes that your disc is basically full, or with the
$files distributed evenly across the disk. i also dont remember were
$exactly the fat table is on msdos and i dont know how often msdos
$read/writes it. i suppose if the fat table is at the front of the
$disk and you dont have any disk caching, then yes, the front of the
$disc is where you want to put important stuff.
Yup, all the administrative stuff (except for subdirectories) is
at the front of a DOS disk - the FAT and the root directory, primarily.
This is why it makes sense on DOS to have the most important files at the
front of the disk.
$
$-wayne
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
"I want to look at life - In the available light" - Neil Peartdmurdoch@watstat.waterloo.edu (Duncan Murdoch) (01/18/90)
In article <25B49A6D.23757@maccs.dcss.mcmaster.ca> cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) writes: > > Yup, all the administrative stuff (except for subdirectories) is >at the front of a DOS disk - the FAT and the root directory, primarily. >This is why it makes sense on DOS to have the most important files at the >front of the disk. No, all the administrative stuff is at the front of a DOS _partition_. It sounds (from the original post, about putting it in the middle of the disk) as though it would be worthwhile setting up the most heavily used partition about halfway through a disk, so that its FAT ends up in the middle tracks. Duncan Murdoch
emmo@moncam.co.uk (Dave Emmerson) (01/19/90)
In article <1360@mitisft.Convergent.COM>, burton@mitisft.Convergent.COM (Philip Burton) writes: > > > >Whenever I've formatted a hard disk I always begin by building the directory > >trees first, (that is, with NO FILES IN THEM). I have a small batch file > >on floppy which does most of this automatically. Another small programme > >creates this batch file if I want to copy/rebuild an existing disk. > > Any chance you could post these small batch files. They sound genuinely > useful. > I was quite surprised to get a few requests for this. I haven't the cheek to submit it to a .sources, you'll see why: It's just a few lines of basic (it wasn't worth any more effort than that). First, from DOS, enter TREE > TREE.TXT on the drive to be replicated. TREE.COM should be in your dos bundle. Then run the compiled basic programme, with a floppy in drive a: it produces a file on a: called diskdir.bat. After you've formatted and partitioned your new HD, log onto it, and run a:diskdir. I compiled it with Quickbasic at work, it shouldn't need much to port it to anything else, TREE did all the hard stuff. 'Nuff said, here it is.. Enjoy! Dave E. < cut here > rem Copyright and all rights donated to the public domain, D.J. Emmerson, rem 18th January, 1990. rem Quickie for creating a batch file to duplicate a directory tree structure rem onto a clean partition or new disk. rem Before running this, enter the following DOS command : rem TREE > TREE.TXT rem This programme expects to find the TREE.TXT file in the current drive rem and generates a batch file called DISKDIR.BAT on drive A: rem Diskdir.bat will create the directory tree structure on the new rem partition, BUT WILL NOT TRANSFER THE FILES INTO THEIR DIRECTORIES, rem as it cannot guess which ones should be copied first. rem This is crude, and has no error-checking, but it is simple and quick. print "Emmo's Batchfile generator for Directory Tree replication" print "Freeware Version 1.01, Aug '88" open "tree.txt" for input as #2 open "A:\diskdir.bat" for output as #3 for doline = 1 to 1000000 line input #2,l$ x = instr(l$,"Path") if x = 0 then goto TESTEOF l = (len(l$)) - 7 o$ = right$(l$,l) print #3,"mkdir ";o$ print o$, TESTEOF: if EOF(2) then close: Print "ALL DONE!" : system next doline
kmont@hpindda.HP.COM (Kevin Montgomery) (01/19/90)
> actually on the mainframe systems i used to administer, we tried to > keep the most used/important files in the center (middle track) of the > disk. that keeps the max seek down to 1/2 of the disc, and the average blah. AT&T filesystem. note that this whole discussion varies greatly depending on the filesystem in use- BSD, for example, uses concentric rings of i-nodes and data blocks, so that it's never far from one to the other. MSDOS probably keeps the directory info in one place. Dunno about AFS or Xenix. just remember, your mileage may differ... -bop
bcw@rti.UUCP (Bruce Wright) (01/20/90)
In article <1316@maytag.waterloo.edu>, dmurdoch@watstat.waterloo.edu (Duncan Murdoch) writes: > In article <25B49A6D.23757@maccs.dcss.mcmaster.ca> cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) writes: > > Yup, all the administrative stuff (except for subdirectories) is > >at the front of a DOS disk - the FAT and the root directory, primarily. > >This is why it makes sense on DOS to have the most important files at the > >front of the disk. > > No, all the administrative stuff is at the front of a DOS _partition_. It > sounds (from the original post, about putting it in the middle of the disk) > as though it would be worthwhile setting up the most heavily used partition > about halfway through a disk, so that its FAT ends up in the middle tracks. It really doesn't make much difference whether you talk about putting the most heavily used partition in the middle of the disk, or the administrative overhead within each partition into the middle of each partition. Both techniques will tend to reduce head movement time; in fact, a strong argument could be made that they are essentially the _same_ technique, just employed at different levels of the disk structure. An optimal file placement strategy is difficult and unique to each user; however in the absence of other information, placing things like the administrative overhead for each partition in the middle of the partition means that the heads have to move at most 1/2 the width of the partition in order to get from the directory/FAT area to the file being opened/closed/ whatever; the expected distance will usually be significantly shorter (and will depend on file placement and frequency of reference). Likewise, if a program was using files in the most-heavily-used partition, and then opened a file in another partition, the expected head movement would usually be smaller if the most-heavily-used partition were in the middle of the disk. Most high-end operating systems use techniques like this, to squeeze as much as possible out of the disks. The effect is somewhat incremental compared to defragmenting a disk drive or careful design of the on-disk data structures, but it is quite real and is a fairly easy way of increasing the performance of just about _any_ file system design. For what it's worth OS/2's new HPFS (High Performance File System) uses such techniques, amoung others, to achieve its performance. Bruce C. Wright