Considering a new RBF

  • Boisy Pitre

    Boisy Pitre - 2007-02-14

    This thread is intended to spawn thought and discussion on a possible new replacement to the existing RBF.  I've listed a few of what I consider to be RBF's limitations:

    Limitation 1:  A "locked-in" 256 byte sector size limit
    Notes: All modern storage devices have 512 byte sector sizes.  CD-ROMs have 2048 byte sector sizes.  To make these work with RBF, the driver must use debocking techniques to fool RBF into thinking it is dealing with a 256 byte sector device.

    Limitation 2:  A 29 character filename limit
    Notes: I don't find that this isn't a limitation in practice, but a newer block file manager might extend this easily, at the cost of increasing the size of a file's entry.

    Limitation 3:  A 24 bit LSN
    Notes: The next logical expansion is 32 bits.  However, a lot of system calls would have to change to accommodate the extra 8 bits; but do we really need 4GB drives on an 8/16 bit OS?

    Limitation 4:  A 65,535 byte bitmap
    Notes: each bit of the bitmap corresponds to one 256 byte sector.  Increasing the sector size to 512 bytes would double the number of bytes the bitmap would cover.

    Limitation 5:  No 'seconds' field in the creation/modification time
    Notes: This can be a pain with programs like make, who use file dependencies to determine behavior.  Adding a seconds field is definitely a good idea.

    Limitation 6:  Lack of a file 'creation' time stamp for files
    Notes: It would be nice to know the time that a file was created, not just the date.

    This list doesn't even address possible performance bottlenecks. 

    Comments are welcome.

    • tim lindner

      tim lindner - 2007-03-13

      I think these are all good ideas.

    • Diego Barizo

      Diego Barizo - 2008-02-08

      They all sound good, but if it cuts some work, Points 2, 3, 4 and maybe even 6 could be left out.
      At least 1 and 5 seem to be the higher priority ones.
      Is software a bottleneck in this case? Hardware might be the biggest issue when it comes to speed.

    • Gene Heskett

      Gene Heskett - 2008-06-20

      Pursuant to my other note in the joydrv thread, something has fallen through the cracks in the record locking code in rbf these days, the net result being that if one is generating a listing that is being written to disk, and the list program is 'tailing' that write, is has become possible for that tail to overtake and pass the writer and get garbage data from allocated but unwritten as yet sectors of the disk.  This garbage data has even crashed either "list" or the underlying shell a couple of times recently.  This used to be extremely bulletproof.

      Cheers, Gene
      "There are four boxes to be used in defense of liberty:
      soap, ballot, jury, and ammo. Please use in that order."
      -Ed Howdershelt (Author)
      All of life is a blur of Republicans and meat!

      • Robert Gault

        Robert Gault - 2008-06-21

        The locking code in Level2 rbf looks pretty complicated to me. I don't know whether it was supposed to do this but my guess is the logic should be ....
        1) Assign a minimum number of sectors and lock them all.
        2) Write a sector and unlock it.
        3) Continue until file is complete, assigning and locking new blocks of sectors as needed.
        4) Unlock and de-assign unused sectors.

        If something like the above is not done, then eventually you would have to read garbage if you list a file in the process of being written.

        What I don't see is any advantage of listing the output of the assembler, while it is assembling source code rather than just asking the assembler to do the listing. What am I missing?

        • Gene Heskett

          Gene Heskett - 2008-06-21

          Historically, rbf has locked only the sector being written, and I assume that it locked the next sector when the current one was full, before unlocking the previous one.  This prevented the list command from overtaking the writing of the file.  my guess is that somehow, when it has to allocate a new block of sectors, there is a tick or two when there is not a lock, so list overshoots.

          It may also be an artifact of more than 1 sector clusters, so when I get to that, I will see if this gotcha exists when tailing a file on a single sector cluster floppy.  I suspect that might be educational too.  If it doesn't do it there, that will point the finger closer to the target.

          Question?  How far away from my last release is the current version?

          My version had no support for non-256 byte sectors, and if I'm reading between the lines correctly, it now has the ability to handle a cd's 2048 byte sectors too, and it may be something in that area doing something funkity.

          As for using list to tail the file, I always have the assembler write a listing that can be printed in due time as I find I can understand the code much better when it is on hardcopy.  That may be a leftover in todays world, but it sure lets me xref mistakes a lot easier.

          Cheers, Gene
          "There are four boxes to be used in defense of liberty:
          soap, ballot, jury, and ammo. Please use in that order."
          -Ed Howdershelt (Author)
              "I thought you were trying to get into shape."
              "I am. The shape I've selected is a triangle."

  • Allen Huffman

    Allen Huffman - 2015-01-30

    Wow, some great discussions back then. How many of these does the OSK file system take care of?



Cancel  Add attachments

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks