On Tuesday, February 7, 2017 at 6:38 AM, Paul Koning wrote: > > On Feb 7, 2017, at 4:28 AM, Mark Pizzolato <[email protected]> wrote: > > > >>>> ... > >> > >> A possible complication with RSTS: I can't find the precise device size > >> because > >> that isn't stored anywhere in the file structure. What I can find is the > >> size > >> rounded up to the next multiple of 4096 times the cluster size (from the > >> free > >> space bitmap size in blocks, since each bit represents a free cluster). I > >> can also > >> find a lower bound, from the end of the last free cluster in the bitmap. > >> But if > >> some of the space at the end of the pack is in use -- not all that common > >> but > >> certainly possible -- then that doesn't help. > > > > Well, what you can do would actually be fine. If the disk size was limited > > to > > the furthest place user program data could be written in the file system, > > then > > the problem would be solved. If someone using a 3.x simh version actually > > wrote > > beyond that, then the size would already be reflected in the container's > > size > > which would then be larger. The problem this is really solving is the one > > when > > we were limited to determining the size of the disk by the size of the > > container > > which might not have been completely written to. > > Ok. Looking at the free space bitmap will produce an upper bound, possibly a > loose one. I'd want to pick a valid size for the device in question so the > drivers > don't freak out. Are there standard tables of possible sizes for the various > devices? If not then I'll need to add those, for all models other than MSCP > where any size is valid.
That problem is handled in each of the device simulators which both 1) do auto sizing and 2) know about the set of possible disk types/sizes that the device controller supports. The question that needs answering is: Does this disk image contain a recognized file system, and, if so, how big is that file system. An additional nicety would be to display the volume label if that is a meaningful detail in the file system being recognized. > > If auto sizing restricted the disk to be the largest space the file system > describes, > > then no useful activities would write beyond there and the exact disk model > > wouldn't be important. Right? This whole activity is to support correct > simulator > > behavior when using a disk container created with a 3.x simulator. All RP > and RQ > > disks created with the 4.x code will write the first and the last blocks in > > a > newly > > created disk. The comments around the code that does this says: > > > > On a newly created disk, we write a zero sector to the last and the > > first sectors. This serves 3 purposes: > > 1) it avoids strange allocation delays writing newly allocated > > storage at the end of the disk during simulator operation > > 2) it allocates storage for the whole disk at creation time to > > avoid strange failures which may happen during simulator > > execution > > if the containing disk is full > > It doesn't actually achieve that if the file system supports sparse files, as > many > Unix systems do. OK. I'll change it to write the whole file with zeros. - Mark _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
