Summary of responses to file allocation , plea for changes in Unix

[Doug Karl]

This is a summary of the responses I received from an earlier posting.
With a plea for help in adding an allocate function to future releases of
Unix.

REVIEWING EARLIER POSTING:

I am in desperate need to allocate a Unix (BSD 4.3, SUN/OS, System V, and
NeXT/Mach) file prior to using it.  By "allocate" I mean that all of the
blocks in the file (10's of megabytes long) should be reserved to that
file instantly). This is possible on all other operating systems except
Unix, because Unix allocates blocks to it's file only when they are first
touched (or written into).  This is a well known characteristic of the
Unix file system.

What I am doing is recording several channels of CD/DAT quality sound
simultaniously on generic SCSI disks attached to a computer using a
special SCSI disk controller. The SCSI disk controller sits between the
SCSI bus on the CPU and the disks (it has 2 SCSI ports). It is operating
system and file system independent and therefore works on Unix (assuming
SCSI disks).  BUT it expects that a file is fully allocated by the
operating system prior to recording (so it knows where on disk to put the
data) which takes a fraction of a second on VMS, MS-DOS, and MAC/OS but
takes several minutes on Unix. This is because I have to write out each
block of the file for it to be "fully" allocated.  After the file is
allocated then I mearly write to the SCSI disk controller the files
logical block mapping and it then can record the sound.  Playing or
re-recording is no problem since the file is already allocated.

This is a very significant problem since for the typical example of a Unix
based 16 track recording studio, recording a song 2 minutes long would
take 16 minutes to allocate the files (using the write each block method).

SUMMARY OF RESPONSES:

- Many people suggested forgetting the Unix file system and writing my own.
  --> Ruins the beauty of using existing Unix tools and file system <---

- Others (mostly data base people) said they have the same problem and wrote
  their own file system using a raw partition but the code is propriatory.
  --> Oh well <--

- Some are writing compressed video to disk and have the same problem.
  --> This is another reason to get fast allocate to work on Unix <--

- Some misunderstood the question and told me that Unix was a multi-user 
  system and suggested I post the request to the MS-DOS news group.
  --> ???? <--

- Some misunderstood the problem and suggested using mkfile.
  --> This would still take 16 minutes to setup for 2 minutes of recording
      since it does a write to each block in order to allocate a file. <--

- Some suggested I record to a raw partition and then copy to a Unix partition
  --> This would take 32 minutes to copy after the 2 minutes of recording <--

- One person pointed out that when I write the blocks they had better not be
  full of zeros or the blocks would still not be allocated on some flavors
  of Unix.

- One person commented that holey files have been a thorn in the side of Unix
  for years and that is just the way it is! (maybe he ment holy files).

The best response was from an engineer at SUN who suggested modifying Unix
to perform the allocate function directly. I presume this would be a
kernel mod that would have to be provided on all of the Unix platforms and
be compatible with NFS. I did find someone who said they have a kernel mod
to do such a thing but I have not received it yet.

PLEA!!:

How do I get the Unix software design engineers and standards community to
consider modifying future releases of Unix of all flavors to allocate
files?  With computer based audio recording studios and compressed video
to disk hitting the streets, isn't it a good idea for Unix to be there
too? I see this as a critical issue and easy to fix shortcoming of the
Unix file system.  Is there anyone out there who grasps the importance of
such a modification to data base and real time users of Unix and who sees
that such a modification would not be a hinderance to Unix but an
enhancement???

Please respond to me directly with ANY ideas and I will summarize:

THANKS...

Doug Karl,
Senior Computer Specialist
Instruction and Research Computer Center
The Ohio State University
karl-d at osu-20.ircc.ohio-state.edu
(614) 292-4843 (please feel free to call)