Maybe I'm missing something, but surely just setting blocksize to 4096 instead of 512 bytes in MediaToolBox for the filesystem is all this requires?
Potentially the RDB might need resizing to be a multiple of 4096 bytes (I have no idea how much space the RDB reserves at the start of the drive) to avoid data alignment issues.
JXFS might need an update as IIRC it won't work if blocksize isn't set as 512 bytes.
No, it needs a large part of the filesystem to be rewritten in each case. I can't remember the details now (we discussed it some months ago), but it's not a trivial task.
@logicalheart That article from Seagate does not seem to share your optimism. And why the panic about 4K support if it's a non-issue?
Also, why should HD manufacturers (whose margins are razor thin) want to manufacturer two almost identical drives - that's just more cost to them, and more confusion in the market place. Seems to me they'll want to phase out the old ones very quickly - basically as quickly as the market will allow (which might be very quick since Windows 7 & OS X fully support 4K, while Linux isn't far behind).
Do you have any good reasons for thinking what you said?
Maybe I'm missing something, but surely just setting blocksize to 4096 instead of 512 bytes in MediaToolBox for the filesystem is all this requires?
Potentially the RDB might need resizing to be a multiple of 4096 bytes (I have no idea how much space the RDB reserves at the start of the drive) to avoid data alignment issues.
I *think* (don't know for sure) what you say should make a BIG improvement to the performance, and something which those technically able should be able to do, but it will be error prone, and most users won't be able to do it. Much better for it to be handled automatically by the partitioning program (which could even keep sectors at 512 byte size).
@tonyw Quote:
No, it needs a large part of the filesystem to be rewritten in each case. ... it's not a trivial task.
Surely it's not a problem as long as the 512 byte blocks are aligned with 4KB boundaries, thus not overlapping any 4KB boundaries? This is the main source of the performance problem, as the new 4K drives handle emulation of 512 byte sectors fairly well otherwise.
Sorry if I'm missing something here, but isn't block size, etc. something dependent on the filesystem in use, and nothing to do with the physical geometry of the platter? Surely they aren't hard formatted, that hasn't been common practice for 30 years?
If the HDD controller internally can only read blocks of 4KB at a time, which is how SSDs work, incidentally, then to read a block at any other point (which is what AmigaOS would do if it expects 512B blocks) it would have to read the whole 4KB in anyway.
I suspect reading it will make little difference, as the 4KB lump will go straight into the cache. The problem will be writing, as the HDD will have to: 1)Read 4KB 2)overwrite a 512B sector 3)Write 4KB for every block write. This is what SSDs do already.
I don't know this, but I'd suspect it's all to do with standardisation with SSDs, and maybe also to do with huge disk sizes as they may need a standard (not sure how big the current LBA standard or whatever can cope).
I don't know this, but I'd suspect it's all to do with standardisation with SSDs, and maybe also to do with huge disk sizes as they may need a standard (not sure how big the current LBA standard or whatever can cope).
The current limit with 512 bytes/sector is 128 EB (134,217,728 GB).
The main reason they are changing the sector size form 512 to 4096 bytes is to make the HDs cheaper, or actually larger for the same price. The real size of a HD is much larger than the size you can use, for each sector there is a lot of additionl data stored for data recovery, even if a lot of bits are wrong in a sector the HDs can recreate the data that way. With only 1/8 but larger sectors there is much less such data stored (more than for a 512 bytes sector, but much less than for 8 512 bytes sectors) and much more of a same sized HD can be used for user data. In case there are too much errors to restore the data in a sector you'll lose 4096 bytes instead of the 512 bytes now, but if it's not a data sector of a file but file system meta data you lose much more data anyway, and even if it's just a file data sector it doesn't matter much for most files if 4096 or only 512 bytes of the file are unreadable/wrong.
The problem will be writing, as the HDD will have to: 1)Read 4KB 2)overwrite a 512B sector 3)Write 4KB for every block write.
I don't think for *every* write, because HDs these days have humongous caches (e.g. 8MB), so there is a good chance several consecutive blocks get written to the cache before the cache gets flushed to the disk.
Quote:
then to read a block at any other point (which is what AmigaOS would do if it expects 512B blocks) it would have to read the whole 4KB in anyway.
I suspect reading it will make little difference, as the 4KB lump will go straight into the cache.
Correct, according to what I read anyway.
@ssolie Sorry if this appears scare-mongering, I just hadn't realised that this 4KB switch-over had such an immediate (and potentially sharp) deadline. And the performance problem is real. Personally I prefer not to ignore foresable problems...
I'm planning to replace my existing PC hard drives ASAP, so that I don't have to worry about this c**p for the next few years (by which time it should be a non-issue).
Anyway, be assured I won't be starting any more threads about this issue.
@Antique Quote:
Will the os4 filesystems support this soonish? Like sfs and jxfs?
I'm not hopeful about SFS, since it is effectively end-of-lined by JXFS.
@Minuous Quote:
Sorry if I'm missing something here, but isn't block size, etc. something dependent on the filesystem in use, and nothing to do with the physical geometry of the platter? Surely they aren't hard formatted, that hasn't been common practice for 30 years?
I'm no expert (by a long way) but I think computers *talk* to the harddisk interface in terms of blocks, sectors, cyclinders, etc. So each location on the harddisk has a specific "address". And the harddisk is optimised/forced to read/write a minimum amount of information in one go (several adjacent addesses).
I'm purchasing some hard drives for my VMWare ESX servers and noticed there is a good selection available now for 4k drives at a lower price than the older 512B drives. As I mentioned 5 years ago, there are still plenty of new 512B drives available.
It will be at least another 5 years before I get concerned about 4k drive support in OS4, but I'm curious if anyone has tested them, or heard any news.
@logicalheart I was under the impression that all consumer HDs are 4K models these days. What brand are these 0.5K models? And where are you finding them for sale?
Quote:
I'm curious if anyone has tested them, or heard any news.
Wouldn't it have been more appropriate to start a new thread?
few days ago I installed a new hard drive for my Sam440ep and it is a 1TB hard drive.. Then i red this thread and for curiosity I checked my hard drive.. It is a Toshiba and it is a 4k hard drive..
well it works (at least until now, fingers crossed )
I have several partitions on it. I just tested copying 383MB of mixed files (some code and some music) from RAM: to one SFS/512 partition and one SFS2/4k partition.
Copying to the 4096 block size SFS2 partition was about twice as fast, at 40.7MB/s vs. 20.3MB/s to the SFS/512 partition. Note: This disk is a 2TB WD Caviar Green energy saving disk, so not optimally fast.
Anyway, I don't think SFS2 is that much faster than SFS1, much rather does the 4k block size make it faster than using 512 byte block size.
When I created the partitions I was very careful to place the partitions on a 8-cylinder boundary, assuming Partition Wizard thinks in 512 byte terms. So if you know what you're doing, you can take advantage of the 4k drives on Amiga as well
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
well it works (at least until now, fingers crossed )
Of course it works. 4K drives work fine on AmigaOSs... just very slowly (especially write performance), unless you are very careful to set-up the partitions like Deniil apparently has.
@Deniil Quote:
4096 block size SFS2 partition
Beware that, AFAIK, such block sizes are extremely UNsupported by Hyperion. Only 512 block size is officially supported, and other sizes may cause problems/corruption.
Having said that, I *had* to use 1024 block size on my largest SFS2 partition (for some years without any problem), otherwise AmigaOS couldn't handle it. So we really need a new filing system which officially supports larger block sizes, even when using large 0.5K drives!
Sadly those specs fail to mention the sector/format size either.
I also conclude that these allegded 0.5K drives are no-longer being manufactured since the middle of 2014, and so any available on Amazon are "old stock". So if they ARE 0.5K drives, then I better buy one ASAP!
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
)
