My understanding was that hard drive manufacturers had announced the move to 4K sectors back in 2010, and 4K sector support has been present in operating systems since Windows Vista. Yet I just checked my brand new Samsung 980 PRO 2TB SSD and it reports 4K physical sectors but an emulated 512 byte interface. Same with my 8TB Seagate. I find it odd that its been more than 10 years and drives are still presenting themselves to the OS as if they are 512 byte sectors.
Misalignment - as others pretend - only results in performance degradation and additional hard drive wear but is no reason for a harddrive to show virtual sectors with a size of 512 bytes. It is rather the opposite:The effort to maintain compatibility by showing sectors of 512 bytes to the world outside of the hard drive which then have to assigned to internal sectors of 4096 byte by the firmware of the hardware causes alignment problems.
Oh noooo it wont format will it require something arcane? Nah. This is just the drives way of telling you that it is destructive. Different kinds of drives require different massage here. You might have to do something like
Sometime in approximately late January 2023, my workgroup began having difficulty exporting PDFs from InDesign to our Google Drive. The PDF files appear on the Drive but as 0 bytes and can't be opened/viewed from the Chrome side of the Drive. We have isolated the problem as specific to anyone who is on MacOS Ventura. We believe the problem stems from a late January/early February upgrade to either the Google Drive, InDesign or Ventura (or perhaps a perfect storm combo of all three). We have 8 InDesign users in our workgroup and only the three who upgraded to Ventura are experiencing this problem. The PDF files on our Google Drive can be viewed and behave normally when accessed through Finder on the Mac side by the author of the PDF file. When accessed through Chrome on the Google Drive side, they appear as 0 bytes. The workaround we discovered is to drag the PDF from the Finder window into the Chrome window, replacing the PDF file on the Chrome side, at which point it acts normally for everyone. Every time the PDF is modified, the process has to be repeated.
Giving the Drive "time to sync" is not the issue as we've gone back and checked bad PDFs 24 hours later and they are still bad. PDFs exported from other CC apps behave normally, as do other file formats (JPG, PNG, etc.) exported from InDesign so this is definitely a very specific ID + PDF + Ventura + Google problem.
My team has the same problem. In addition to this, the inDesign files themselves don't save for the group unless the last person who touched them makes a copy of the file with a new name. We do think we're going crazy.
the 0 bytes size PDF files if renamed from mac finder are synced.
PDF files of zero byte size, if not renamed but moved to a new folder, are synced from drive (in the new folder) but their 0 byte version is still visible within the original folder.
Hi there.
We have exactly the same issue and it's strangely reassuring to know that I'm not going mad and imagining this.
Let me know if you find any solution or have any more information on the issue.
Thanks
Sean
All of your personal information, including email address, name, and IP address will be deleted from this site. Any feedback you have provided that others have supported will be attributed to "Anonymous". All of your ideas without support will be deleted.
Did you know that there is a park in San Jose named after a disk drive? Actually, technically it is named after the first computer that used disk drives. You couldn't just go and buy a disk drive peripheral on its own. We're talking about 1955.
Relevant for this piece is that he worked for IBM for years in the era when employees would joke that IBM stood for "I've Been Moved" since they operated a little like the military and moved people around a lot, especially anyone who seemed likely to rise through the ranks. I know the feeling since my father was an officer in the Royal Navy, so I'm what in the US is called a "navy brat" although I don't know of an equivalent phrase in Britain. When Gary decided to switch from being purely technical to management, he was sent to San Jose to work in the management of IBM's disk drive manufacturing facility on Cottle Road in San Jose. Eventually, IBM got out of that business by selling it to Hitachi and gradually the large campus closed. Some of it is still there, although it is surrounded by a high fence to keep you out of the empty parking lots. The buildings are like nothing in Silicon Valley today, more like some buildings escaped out of an Austin Powers movie...they are "really groovy".
Gary told me that he had heard that part of the campus had been turned into a park named after the original product that the campus was created to manufacture. Indeed there is. That's the park sign at the start of this post.
The IBM 305 RAMAC was the first computer system with moving head disk drives. It was announced in 1956, although there were already what we would call beta sites up and running by then. It was built with vacuum tubes, one of the last before IBM switched to transistors.
RAMAC stood for Random Access Method of Accounting and Control since its design was motivated by real-time business accounting. In that era, IBM only leased machines and didn't sell them, which would eventually result in an anti-trust lawsuit decades later, but that's a story for another day. They also got hit with an anti-trust lawsuit over their large market share in...typewriters. Good job the US government got that one sorted out or we'd have no choice in what typewriters we have to choose from today. A 305 RAMAC leased for $3,200 per month. Mr Google tells me that is $31K per month in inflation-adjusted dollars.
They have a RAMAC disk in the Computer History Museum (currently closed to visitors, of course). Here's a picture I took of that unit. It's hard to get a sense of scale at a glance, but notice the normal-sized electrical double switch to the left of the unit. The disks are two feet across.
You might assume that this disk drive was just for storage and that it had a RAM of some sort to go with it. But it had a magnetic drum memory where the instructions were held, rotating at 6,000 rpm, which held 3.2K bytes. A typical instruction took 30ms, three revolutions of the drum (what today we would call instruction fetch, operand fetch, writeback). But some were slower. Divide took 10 to 37 revolutions.
Since IBM refers to the "up" and "down" surfaces, and the unit in the CHM is vertical, I assume that was the way it was used. But the original disk drive patent shows it horizontal. I'm guessing IBM switched because that eliminates gravity from the mechanics. For much the same reason, we switched from horizontal to vertical furnaces for diffusion in semiconductor processing when we went from 8" to 12" wafers.
If you want to see this fascinating historical document, essentially the fundamental patent on the disk drive, it is US patent 3,503,060. Ignore the date on the top right, that is just when this continuation was filed. If you look at the block of text at the start of the patent itself, you can see it was originally filed in 1954.
DIsk drives didn't seem to have a high-profile individual in the same way as Gordon Moore set the roadmap for semiconductors for decades without really intending to, and "Moore's Law" became something that you might even read about in the mainstream press. Of course, disk drive controllers have benefited from advances in semiconductors. But the density of recording magnetic drives went up even faster than Moore's Law for completely different reasons. Without those advances, we risked having PCs just as we did, starting in the 1980s, but without any hard disks (and don't forget, none of the Apple II, the first Mac, nor the first PC had hard disks). How about a 3GHz PC with floppies. Or with a hard disk weighing hundreds of pounds. But, in fact, you can buy a 1TB hard drive for $44.99 today.
To put terabytes in perspective, RAMAC disks were 5MB, weighed a ton, and had to be delivered with a forklift. A million times bigger would be 5TB, just a bit bigger than the drives you can buy online with the click of a button, shipped to you overnight in a small box.
As I said, you can see a RAMAC disk at the Computer History Museum in Mountain View, assuming one day we are allowed to visit again. I recommend a visit (not just to see the RAMAC disk, of course). For a little more detail, see my post Computer History Museum History,
I can't honestly recommend a trip to IBM Cottle Road and RAMAC Park unless you really, really want to say you've been there. IBM is largely closed off, and the park is just like any other park except for the name. I didn't see anything that even explained what RAMAC was. But Google Maps knows just where it is if you decide to go. It's certainly a piece of Silicon Valley history, if you can count the most southern part of San Jose as still in Silicon Valley:
I am troubleshooting database performance problems and I can clearly see that the database is IO bound. The server has a SAN with a 1 gigabit network connection. The network engineer has tracked packets and says that this is all the Windows (2003) server is requesting and the SAN/network delay is < 1ms usually, with an occasional 2 ms. delay. The delay I see is much greater. This test was done with a file copy from one SAN drive to another to eliminate the database from the equation.
What I'm wondering is what type of performance should be expected with this configuration. My Disk Bytes/sec counter is reading around 34MB/sec. This seems very slow to me and accounts for the slow database. (It's 4TB with many multi gigabyte queries.) I would appreciate it if someone who knows these can confirm or deny that this is a slow value. This will help me know if we need an upgrade or tuning.
c80f0f1006