[Info-vax] Assembly languages

gah4 gah4 at u.washington.edu
Tue Apr 12 04:30:07 EDT 2022


On Monday, April 11, 2022 at 11:42:00 PM UTC-7, Johnny Billquist wrote:

(snip, I wrote)
> > Disk files on Unix-like systems and DOS/Windows are just a string of bytes. 
> > Any block structure is hidden by the OS disk cache.

> Well, it's not hidden by the OS disk cache in Unix. It's hidden by the 
> device driver framework. That's where the block and character devices is 
> about.

If you do a read() system call on a disk file, it either fills the buffer or
writes the bytes left in the file. There used to be a rule that you should
never use the block disk device.  That restriction might be gone, but I
am not sure what happens if you do use it.  When I do write raw disk
devices, I use the character device. 

> > On the other hand, tapes on Unix, and I believe DOS/Windows do have a block 
> > structure. In some cases, it is necessary to preserve that in order to 
> > properly read them. There are virtual tape formats that convert a tape of 
> > blocks into a stream with block marks included, and others to reverse it.

> Actually, in Unix, tapes are the same story as disks. However, no sane 
> person ever cared to use the character device for tapes, since (as you 
> observe), with tapes there are additional reasons why you want to know, 
> and preserve block information. The character device hides this from you. 
 
All the Unix tape work I ever did was with the character device. 
Maybe 20 years ago, we did it with tar, where you tell tar the blocking
factor that you want, and it writes blocks of that size to tape.

The Unix read() system call on a tape character device returns one tape
block, and the length of that block.  On 9-track reel tape drives that I know,
you can write any block length you want, with the drive writing the block,
and an inter-block gap to the tape.  Some other tape systems only allow
for fixed sized blocks. 

More recently, I was working with Ultrium (LTO) drives, which have two
modes.  In one mode, the drive writes fixed length (usually 512 byte)
blocks, the other looks more like 9-track drives.  Though in the case
of LTO all the blocking is virtual. Having the drive in the wrong mode
confuses programs like tar.

> For networking, it's all carried by IP datagrams in the end, which are 
> blocks. TCP then implements a stream of bytes abstraction on top of that. 

Yes, but TCP won't tell you were the boundaries were before the data
went into the TCP stream, or where the IP boundaries were.



More information about the Info-vax mailing list