cmw1725@tamsun.tamu.edu (Christopher Walton) (03/23/91)
Could someone please mail or post the specs for FFS to me... I need to know what tracks it reserves for its own use, and what is put there. I also need to know what the track size is, the blocks per track, etc.... Thanks Christopher Walton cmw1725@tamsun.tamu.edu
Jay@deepthot.cary.nc.us (Jay Denebeim) (03/26/91)
>Could someone please mail or post the specs for FFS to me... >I need to know what tracks it reserves for its own use, and what is >put there. I also need to know what the track size is, the blocks >per track, etc.... All this stuff is device specific. However the first couple of SECTORS are reserved. The only thing that is fixed is the block (sector) size. That is 512 bytes. > >Thanks >Christopher Walton >cmw1725@tamsun.tamu.edu -- |_o_o|\\ |. o.| || The Jay Denebeim | . | || Software | o | || Distillery | |// Address: UUCP: mcnc.org!deepthot.uucp!jay ====== Internet: jay@deepthot.cary.nc.us BBS:(919)-460-7430 VOICE:(919)-460-6934
ccplumb@rose.uwaterloo.ca (Colin Plumb) (03/27/91)
cmw1725@tamsun.tamu.edu (Christopher Walton) wrote: >Could someone please mail or post the specs for FFS to me... >I need to know what tracks it reserves for its own use, and what is >put there. I also need to know what the track size is, the blocks >per track, etc.... The FFS doesn't enforce any track size, blocks per track, or whatever. It just wants blocks numbered x through y, for some x>0. As of 1.3, it only liked 512 byte blocks, but that might be fixed in 2.0 - I don't know. On floppies, it uses the low-level trackdisk.device format. I.e. 11 512-byte blocks per track per side, for a total of 1760 blocks total. The first two are reserved for boot blocks, and the others are used by the file system. On hard drives, anything goes. In any case, if the last usable block is y, then both the old and new file systems use block (y+1)/2 to store the root block, and usually allocate bitmap blocks immediately thereafter, but they can go anywhere. FFS's root and directory blocks look just like the OFS's, except that directory hash chains are kept in sorted order, by block number. FFS eliminates the haeder information in data blocks, filling them with 512 bytes of data. It also has some extensions to allow big partitions; after the pointers to bitmap blocks are used up in the root block, one last pointer points to a linked list of bitmap blocks for the rest. Other than that, there's no difference. See the AmigaDOS manual for most of the details, and the DevCon notes for FFS upgrades. -- -Colin
jesup@cbmvax.commodore.com (Randell Jesup) (03/27/91)
In article <1991Mar26.211632.24246@watdragon.waterloo.edu> ccplumb@rose.uwaterloo.ca (Colin Plumb) writes: >The FFS doesn't enforce any track size, blocks per track, or whatever. >It just wants blocks numbered x through y, for some x>0. As of 1.3, it >only liked 512 byte blocks, but that might be fixed in 2.0 - I don't >know. powers of two up to ~32K under 2.0. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
ptoper@obelix (Andy Nagy) (03/29/91)
In article <20154@cbmvax.commodore.com>, jesup@cbmvax.commodore.com (Randell Jesup) writes: > In article <1991Mar26.211632.24246@watdragon.waterloo.edu> ccplumb@rose.uwaterloo.ca (Colin Plumb) writes: > >The FFS doesn't enforce any track size, blocks per track, or whatever. > >It just wants blocks numbered x through y, for some x>0. As of 1.3, it > >only liked 512 byte blocks, but that might be fixed in 2.0 - I don't > >know. > > powers of two up to ~32K under 2.0. As an aside question, what is the upper limit on a hard drive partition size? > Randell Jesup, Keeper of AmigaDos, Commodore Engineering. ------------------------------------------------------------------------------- Andy Nagy (ptoper@asterix.gaul.csd.uwo.ca) The University of Western Ontario, London, Canada "Dee do do do, dee da da da, thats all I want to say to you" -- The Police
jesup@cbmvax.commodore.com (Randell Jesup) (03/29/91)
In article <2603@ria.ccs.uwo.ca> ptoper@obelix (Andy Nagy) writes: > As an aside question, what is the upper limit on a hard drive partition >size? Under some earlier versions of 2.0, it was 500Meg. That's been fixed since then, for the next release. It should be 4 gig, it may be 2 gig if someone blew a signed versus unsigned piece of math. Got a >2gig drive I can test it on? 2.02 and before (and A2091/A590) don't deal properly with >1Gig scsi drives. The next release should fix that (BTW, it turns out both VMS and Ultrix had the same bug - you have to use 10-byte Reads over 1 Gig in scsi.) -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
dave@unislc.uucp (Dave Martin) (04/02/91)
From article <1991Mar26.211632.24246@watdragon.waterloo.edu>, by ccplumb@rose.uwaterloo.ca (Colin Plumb): > > The FFS doesn't enforce any track size, blocks per track, or whatever. > It just wants blocks numbered x through y, for some x>0. As of 1.3, it y-x > 0 ? ... > > In any case, if the last usable block is y, then both the old and new > file systems use block (y+1)/2 to store the root block, and usually > allocate bitmap blocks immediately thereafter, but they can go anywhere. I assume that you mean (x+y+1)/2 ? I would hate to think that if I have a partition from block # 4000 to 5000, that the root block is 2500 and not 4500. 1/2 :-) -- VAX Headroom Speaking for myself only... blah blah blahblah blah... Internet: DMARTIN@CC.WEBER.EDU dave@saltlcy-unisys.army.mil uucp: dave@unislc.uucp or use the Path: line. Now was that civilized? No, clearly not. Fun, but in no sense civilized.
ccplumb@rose.uwaterloo.ca (Colin Plumb) (04/05/91)
dave@unislc.uucp (Dave Martin) wrote: >From article <1991Mar26.211632.24246@watdragon.waterloo.edu>, by ccplumb@rose.uwaterloo.ca (Colin Plumb): >> >> The FFS doesn't enforce any track size, blocks per track, or whatever. >> It just wants blocks numbered x through y, for some x>0. As of 1.3, it > > y-x > 0 ? No, actually. The file system uses "0" as a null vlaue, so it can't use block number 0. Typically, the first two blocks of a partition are left as dummy "boot blocks", so x=2. >> In any case, if the last usable block is y, then both the old and new >> file systems use block (y+1)/2 to store the root block, and usually >> allocate bitmap blocks immediately thereafter, but they can go anywhere. > > I assume that you mean (x+y+1)/2 ? I would hate to think that if I have > a partition from block # 4000 to 5000, that the root block is 2500 and > not 4500. 1/2 :-) No, actually I meant (y+1)/2, because I assumed the partition started with block 0. If you look at your partition from blocks 4000 to 5000, you'll find that DOS uses logical block numbers 0 through 1000. These were the block numbers I was referring to. You can, in the mountlist or partition block, select the number of reserved blocks at the beginning and end of a partition. For historical reasons (namely, floppies, where the root directory is block 880, while block 881 is the middle of the usable blocks 2..1759), the low-end "reserved" blocks aren't counted in the partition-centre computation, but when the high-end "preallocated" blocks were added, they were allowed for, and the partition is deemed to end where usable space ends, which is <# of preallocated blocks> before the end of the partition proper. -- -Colin