karl-d@nisca.ircc.ohio-state.edu (Doug Karl) (06/28/90)
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 falvors
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 compateble
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 short comming 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@osu-20.ircc.ohio-state.edu
(614) 292-4843 (please feel free to call)