[Info-vax] RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was

[David Froble]

lawrencedo99 at gmail.com wrote:
> On Wednesday, June 22, 2016 at 7:04:22 AM UTC+12, David Froble wrote:
>> Lawrence D’Oliveiro wrote:
>>> * I/O buffering, because the underlying ACP/XQP layer only allows reading
>>> and writing whole multiples of 512 bytes (how dumb is that?).
>> You might THINK you're doing something else, but when the data hits the rust, 
>> it's in chunks defined by the disk, usually in multiples of 512 bytes.
> 
> Newer disks have 4kiB physical sector sizes. And then there’s shingle magnetic recording, where writing anything less than a whole track becomes an involved process (remember track buffers on floppy disks?). How well does your 512-byte-multiple restriction fit into this world? It starts to look pretty anachronistic, doesn’t it?
> 
>> Something has got to do filespec parsing.  Better done once than custom code
>> in every application.
> 
> Then there’s the sheer complexity of a VMS filespec. Does the idea of exposing disk device names seem so wise nowadays? On POSIX, you have a pathspec with components separated by simple slashes, and disk device names are completely hidden.

Ah, .... actually, I like to be able to manage where I'm going to locate things. 
  If I need to replace a specific disk, for any reason, all I need to do is 
re-assign the logical names used to ID the disks.

YMMV