home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!ferkel.ucsb.edu!ucsbcsl!mcl!jfoster
- From: jfoster@mcl.ucsb.edu (Joe Foster of Borg)
- Newsgroups: comp.unix.programmer
- Subject: disk buffer size, portable record locking, cabbages, and kings
- Summary: How to maximize portability and efficiency in block-oriented programs?
- Keywords: disk buffers record locking
- Message-ID: <jfoster.720986597@mcl>
- Date: 5 Nov 92 18:03:17 GMT
- Sender: root@ucsbcsl.ucsb.edu
- Lines: 31
-
- [This is a re-post. I can't figure out what happened to my
- original post. Looks like the staff here have been monkeying with
- news again. Aargh! :-(]
-
- I'm currently working on a distributed database library which
- supports variable-length records and BLOBs, for things like
- images, sound samples, formatted text objects, etc. (Right now,
- it's a quite serviceable persistent virtual array library!) I
- want the thing to be as portable as possible, but the only
- systems I current have access to are SCO Xenix/286 2.3.2,
- Xenix/386 2.3.4, and some Sun/3's. I have the following
- questions:
-
- 1) Where is the best place to look for the disk block size? Calls
- to read() and write() seem to be faster when the size of the
- buffers passed to them are the same as the blocks in the kernel
- disk cache. Also, passing arbitrarily-sized buffers to reads and
- writes to raw disk devices seems to bomb. Again, the buffers seem
- to need to be the same size as the blocks in the disk cache.
- What .h file is best to look at? Is the #define fairly standard?
-
- 2) What is the most portable way to do record locking? Currently,
- I'm using fcntl(), since it's present on both the Suns and on
- Xenix and supports both read and write-locks. Is this method
- supported by NFS's lockd and/or other network file-sharing
- schemes?
-
- Thanks in advance for your help!
-
- Joe Foster
- jfoster@mcl.ucsb.edu
-