Talk:Direct-access storage device: Difference between revisions

Computing Start‑class

This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles Start This article has been rated as Start-class on Wikipedia's content assessment scale. ??? This article has not yet received a rating on the project's importance scale.

Really ought to create a 'data cells' page that should in turn link to Early_IBM_disk_storage#IBM_2321 instead of that link being in the See Also of this page. Cpeel (talk) 21:33, 19 May 2008 (UTC)[reply]

There is no "random" access method, and indexed isn't the same as random in any case. This omits partitioned, which is a special case. Peter Flass (talk) 19:38, 24 February 2012 (UTC)[reply]

Seems to me that random access is similar to what IBM usually calls direct access. Gah4 (talk) 04:30, 14 September 2017 (UTC)[reply]

I hated this definition "any secondary storage device which has relatively high access time relative to its capacity." If nothing else it should be fast access time. I'm changing it to paraphrase the IBM manual. Peter Flass (talk) 13:36, 23 December 2013 (UTC)[reply]

I think the paraphrase is almost as bad. "Direct" was coined by IBM to distinguish between "Random" as in core and "Sequential" as in tape; slower than core but faster than tape. The current paraphrase misses the speed point and I suspect is a way after the fact attempt to define without much knowledge of history. I'll look for a better source. Tom94022 (talk) 06:34, 14 September 2017 (UTC)[reply]

The access methods are responsible for blocking and deblocking logical records as they are written to or read from external media. I thought that for BSAM, the user program does deblocking, while QSAM does it for you. Gah4 (talk) 04:32, 14 September 2017 (UTC)[reply]

生朱失失吴矢庆朱余朱矢失辰天吴生矢汪矢矢丿矢生矢生尘矢歹矢失矢生生矢矢生生仕上上令至尖女生矢天兰弓点定斗矢仗止 — Preceding unsigned comment added by 218.189.204.101 (talk) 05:58, 29 November 2018 (UTC)[reply]

If I remember my days with IBM jargon correctly, DASD would be "detachable asynchronous storage device".

Detachable, because it was a separate cabinet, and asynchronous, because it was NOT sync'd to the processor clock for operation. 134.247.251.245 (talk) 13:50, 22 October 2019 (UTC)[reply]

The drives that IBM made for many years are described as synchronous, not because they use the same clock, but because there is minimal buffering between the bits on disk and in memory. For many, it is one or two bytes of buffering. Later on, controllers could buffer a whole disk block, as memory became cheaper. Gah4 (talk) 19:10, 22 October 2019 (UTC)[reply]

Never heard that definition, and FWIW there were IBM DASD in the same cabinets of many small IBM systems. As I understand it they started with Random Access as in RAMAC but ran into a trademark issues so went to direct access to distinguish with sequential and truly random access. 00:14, 23 October 2019 (UTC)

Well, now you make it complicated. On the small systems, the same hardware is shared between CPU and channel operation. When reading, the bits are clocked by the bits coming off the disk on all systems. For writing, they might use the same clock as the CPU, but often not. But data moves slow enough that it is retimed for each transition (usually byte) between disk and memory. Memory systems were asynchronous in internal operation up until SDRAM. (Often relying on delay devices.) But as above, IBM called disk data transfer as synchronous, being retimed byte by byte. Controllers with internal buffers result in data transfers to/from disk being asynchronous to transfers from/to main memory. Gah4 (talk) 00:45, 23 October 2019 (UTC)[reply]

"in which "each physical record has a discrete location and a unique address". This is certainly not true with modern storage subsystems with deduplication built-in, because there files can share identical blocks of data with other versions of the same file, or even with completely different files where duplicate blocks were found to exist. Storage subsystems keep their own records, and copying a file simply creates a new pointer to the same data. Only when the "new" file gets changed, some blocks are newly assigned, containing those changes, and become part of the second file, but not of the first one. The computer normally has no access to the file structure in a storage subsystem, so all of this is unnoticed by the computer. 134.247.251.245 (talk) 14:43, 22 October 2019 (UTC)[reply]

I am not sure about de-duplication, but at the lowest level disk blocks normally have a unique address. At the file system level, it might be that more than one file uses those blocks. Unix uses inodes, where more than one directory entry might link to the same inode, which Unix calls hard links. For flash drives, wear leveling moves blocks around such that repeatedly writing the same block at the file system level doesn't wear out the actual hardware block. Flash memory has limits on how many times each byte can be rewritten. Gah4 (talk) 19:16, 22 October 2019 (UTC)[reply]

I suggest the term DASD is applied uniquely to IBM mainframe systems wherein the quoted statement is true at the IBM OS level. It was physically true into this century. Maybe we can clarify the semantics to make this clear. Tom94022 (talk) 00:10, 23 October 2019 (UTC)[reply]

IBM DID use the term DASD on small systems, too, I remember the OS/2 device driver being named OS2DASD.DMD.134.247.251.245 (talk) 07:40, 23 October 2019 (UTC)[reply]

Maybe, but perhaps the driver is for some sort of mainframe connectivity or emulation in which case the statement might remain true? Or maybe it was just a singular error and not sufficient to redefine the term? As the HDD article suggests DASD is an infrequently used term. Tom94022 (talk) 21:01, 23 October 2019 (UTC)[reply]

No, it's the regular disk management driver on every OS/2 (both hard disk and removable media).134.247.251.245 (talk) 12:28, 24 October 2019 (UTC)[reply]