How do I format a 160GByte drive to only be recognised as 120Gbyte capacity? This is to be used in an an Iyonix so I don't want to go over 120G size to keep the transfer speeds high.
Dentrassis <g...@dentrassis.com> wrote: > How do I format a 160GByte drive to only be recognised as 120Gbyte > capacity? This is to be used in an an Iyonix so I don't want to go > over 120G size to keep the transfer speeds high.
I may be wrong, but I suspect you have to replace it with a 120GB one. Formatting is a software thing, and transfer speeds are a hardware thing; the hardware will still see it as a 160GB device.
In message <20090624141012.70681...@trite.i.flarn.net.i.flarn.net> Rob Kendrick <n...@rjek.com> wrote:
> On Wed, 24 Jun 2009 13:26:33 +0100 > Dentrassis <g...@dentrassis.com> wrote: >> How do I format a 160GByte drive to only be recognised as 120Gbyte >> capacity? This is to be used in an an Iyonix so I don't want to go >> over 120G size to keep the transfer speeds high. > I may be wrong, but I suspect you have to replace it with a 120GB one. > Formatting is a software thing, and transfer speeds are a hardware > thing; the hardware will still see it as a 160GB device.
I remember reading discussion that if a larger drive was formatted down so that it was below 120GB it would still attain the higher access speeds, and in fact one of our Iyonix machines here was supplied as an 80GB model but had in fact got a 160GB drive fitted (by Castle).
I guess that when formatting using !HForm I need to supply figures that reduce the overall capacity, but I'm not sure what they should be. Maybe if I post here the current settings of number of heads etc. that show up as 160GB, someone will be able to help me with what I change to reduce the size. I will fit the drive shortly and have a go.
Dentrassis <g...@dentrassis.com> wrote: > > I may be wrong, but I suspect you have to replace it with a 120GB > > one. Formatting is a software thing, and transfer speeds are a > > hardware thing; the hardware will still see it as a 160GB device.
> I remember reading discussion that if a larger drive was formatted > down so that it was below 120GB it would still attain the higher > access speeds, and in fact one of our Iyonix machines here was > supplied as an 80GB model but had in fact got a 160GB drive fitted > (by Castle).
It might be that the Iyonix cannot use the higher speeds beyond 120GB. In which case, formatting it to 160GB gives you 120GB of fast storage, and 40GB of not-quite-as-fast.
To answer your question: lie to HForm about the number of sectors, but I remain unconvinced of how worthwhile it is.
> How do I format a 160GByte drive to only be recognised as 120Gbyte > capacity? This is to be used in an an Iyonix so I don't want to go > over 120G size to keep the transfer speeds high.
In HForm, adjust the number of cylinders downwards.
eventual_size=512*sectors_per_track*heads*cylinders (in bytes)
Rob Kendrick wrote: > It might be that the Iyonix cannot use the higher speeds beyond 120GB. > In which case, formatting it to 160GB gives you 120GB of fast storage, > and 40GB of not-quite-as-fast.
That's correct, but it isn't desirable to have that 40GB of slow storage, as Filecore doesn't fill the disc lineally from the beginning, so may use that 40GB at any time rather than only when there is 120GB used. Therefor just format to 120GB.
> To answer your question: lie to HForm about the number of sectors, but > I remain unconvinced of how worthwhile it is.
It is worth doing. If the formatting offers you a tracks, heads and sectors values, multiple the number of tracks by 120/160, so you enter a smaller number. (Check the disc size will be just under 120GB by multiplying tracks * heads * sectors * 512). If it offers you logical block addressing multiply the single value (which is 1/512th of the disc size) by 120/160.
>In message <20090624141012.70681...@trite.i.flarn.net.i.flarn.net> > Rob Kendrick <n...@rjek.com> wrote:
>> On Wed, 24 Jun 2009 13:26:33 +0100 >> Dentrassis <g...@dentrassis.com> wrote:
>>> How do I format a 160GByte drive to only be recognised as 120Gbyte >>> capacity? This is to be used in an an Iyonix so I don't want to go >>> over 120G size to keep the transfer speeds high.
>> I may be wrong, but I suspect you have to replace it with a 120GB one. >> Formatting is a software thing, and transfer speeds are a hardware >> thing; the hardware will still see it as a 160GB device.
>I remember reading discussion that if a larger drive was formatted >down so that it was below 120GB it would still attain the higher >access speeds, and in fact one of our Iyonix machines here was >supplied as an 80GB model but had in fact got a 160GB drive fitted (by >Castle).
>I guess that when formatting using !HForm I need to supply figures >that reduce the overall capacity, but I'm not sure what they should >be. Maybe if I post here the current settings of number of heads etc. >that show up as 160GB, someone will be able to help me with what I >change to reduce the size. I will fit the drive shortly and have a go.
Kevin Wells wrote: > Would partitioning it make a difference?
> One partition of 120GB the other 40GB.
Yes, this is effectively what you are doing buy formatting the drive so ADFS only uses the first 120GB. The remaining 40GB could be used by a different filing system. However, I don't know of any suitable on the Iyonix. On the RISC PC there were a couple of ones which could offer additional Filecore partitions (BDFS?) but none are still supported.
> Rob Kendrick wrote: >> It might be that the Iyonix cannot use the higher speeds beyond 120GB. >> In which case, formatting it to 160GB gives you 120GB of fast storage, >> and 40GB of not-quite-as-fast. > That's correct, but it isn't desirable to have that 40GB of slow > storage, as Filecore doesn't fill the disc lineally from the beginning, > so may use that 40GB at any time rather than only when there is 120GB > used. Therefor just format to 120GB. >> To answer your question: lie to HForm about the number of sectors, but >> I remain unconvinced of how worthwhile it is. > It is worth doing. If the formatting offers you a tracks, heads and > sectors values, multiple the number of tracks by 120/160, so you enter a > smaller number. (Check the disc size will be just under 120GB by > multiplying tracks * heads * sectors * 512). If it offers you logical > block addressing multiply the single value (which is 1/512th of the disc > size) by 120/160.
Thanks druck and all others who have replied.
I've reduced the number of cylinders and Formatted the drive. 'Free' from the iconbar menu shows it as 112GBytes, which incidentally matches the size displayed for a real 120G drive I have in another Iyonix.
Now a couple of other questions: Am I correct in setting the parking cylinder to the same (adjusted) value as entered for cylinders? The suggested value was that of the genuine cylinders size, i.e. the last cylinder.
Also, anyone know of a native 32bit disc speed checker? I often use the one that came with my old Powertec SCSI card, but I have to run it under Aemulor on the Iyonix, so it's probably not an accurate test.
On 24 Jun, Stuart wrote in message <507082d89aSpam...@argonet.co.uk>:
> In article <20090624144650.3df5e...@trite.i.flarn.net.i.flarn.net>, > Rob Kendrick <n...@rjek.com> wrote:
> > It might be that the Iyonix cannot use the higher speeds beyond > > 120GB. In which case, formatting it to 160GB gives you 120GB of fast > > storage, and 40GB of not-quite-as-fast.
> I don't own an Iyonix but I do recall there being some sort of issue of > that nature. There are two different methods of addressing the drive > depending on size and keeping the size down means the faster method is > used.
More or less, although as Druck has said elsewhere the first 120GB get accessed in 'fast' mode and the rest in 'slow'. The problem is that ADFS can use the 'slow' bit of the disc at any time, and not just after the 'fast' 120GB has been filled.
Dave Symes wrote: > In article <oyb*8V...@news.chiark.greenend.org.uk>, > Theo Markettos <theom+n...@chiark.greenend.org.uk> wrote: >> Kevin Wells <kevinwe...@talktalk.net> wrote: >>> Would partitioning it make a difference?
>>> One partition of 120GB the other 40GB.
>> It would if ADFS supported partitioning!
>> (It still doesn't, does it?)
>> Theo
> A question if I may. > After all these years why has the RISC OS filing system, and I guess HForm > never been developed to create/support partitioning?
Because RISC OS development has historically embraced NIH, and everyone's done their own thing, and their own hokey version of !HForm (which is dire, incidentally).
There's no reason at all it couldn't be done, and implementation is very trivial compared to other FS nightmares like 2>GB File systems.
On 24 Jun, Dave Symes wrote in message <50709741b1d...@triffid.co.uk>:
> In article <oyb*8V...@news.chiark.greenend.org.uk>, > Theo Markettos <theom+n...@chiark.greenend.org.uk> wrote:
> > It would if ADFS supported partitioning!
> > (It still doesn't, does it?)
> A question if I may. > After all these years why has the RISC OS filing system, and I guess HForm > never been developed to create/support partitioning?
Presumably because no-one at Acorn, RISCOS Ltd, Pace, Tematic or amongst the ROOL volunteers has felt the need to add it?
There may be technical reasons, of course -- I'll leave that to someone more intimate with ADFS to answer.
Dentrassis <g...@dentrassis.com> wrote: > Am I correct in setting the parking cylinder to the same (adjusted) > value as entered for cylinders? The suggested value was that of the > genuine cylinders size, i.e. the last cylinder.
Parking cylinder is completely irrelevant to any drive made since about 1989. That's why HForm really needs some serious work!
On 24-Jun-2009, Dentrassis <g...@dentrassis.com> wrote:
> Also, anyone know of a native 32bit disc speed checker? I often use > the one that came with my old Powertec SCSI card, but I have to run it > under Aemulor on the Iyonix, so it's probably not an accurate test.
!HDspeed on the APDL web site. Simply the best, and it's free :-)
Dentrassis wrote: > I've reduced the number of cylinders and Formatted the drive. 'Free' > from the iconbar menu shows it as 112GBytes, which incidentally > matches the size displayed for a real 120G drive I have in another > Iyonix.
The Iyonix supports UDMA up to 128<real GB> (1024^4 bytes) so you can format it a bit larger than the 120<lying GB> (1024*1000^3).
> Now a couple of other questions: > Am I correct in setting the parking cylinder to the same (adjusted) > value as entered for cylinders? The suggested value was that of the > genuine cylinders size, i.e. the last cylinder.
It doesn't matter, modern IDE drives ignore this.
> Also, anyone know of a native 32bit disc speed checker? I often use > the one that came with my old Powertec SCSI card, but I have to run it > under Aemulor on the Iyonix, so it's probably not an accurate test.
Rob Kendrick wrote: > On Wed, 24 Jun 2009 13:26:33 +0100 > Dentrassis <g...@dentrassis.com> wrote:
>> How do I format a 160GByte drive to only be recognised as 120Gbyte >> capacity? This is to be used in an an Iyonix so I don't want to go >> over 120G size to keep the transfer speeds high.
> I may be wrong, but I suspect you have to replace it with a 120GB one. > Formatting is a software thing, and transfer speeds are a hardware > thing; the hardware will still see it as a 160GB device.
The underlying problem is the IYONIX' ALi southbridge (which is incidentially the same southbridge used in the Omega, and one of the very few PCI-connectable southbridges). It only supports UDMA for the first 128 GB (and that's GiB, not salesmen GB) of any connected 512 bytes/block device.
As long as the LBA block numbers are below 128 GB, UDMA access is used. So if you format the drive to 128 GB, you get maximum speed for the whole harddisc.
On Wed, 24 Jun 2009 19:26:58 +0100, Theo Markettos wrote: > Kevin Wells <kevinwe...@talktalk.net> wrote: >> Would partitioning it make a difference?
>> One partition of 120GB the other 40GB.
> It would if ADFS supported partitioning!
> (It still doesn't, does it?)
Hmm, well ADFS is a filesystem format, so surely it's not its job to know anything about other partitions; an ADFS filesystem just knows the extent of disk blocks that it may access, and in theory there's nothing to stop it co-existing with other filesystems on a larger storage medium.
(in other words it's not an ADFS failing, but an OS failing in that no paritition table format was ever defined*)
* although going from memory, the harddisk for my ancient Econet fileserver essentially had two partitions on it, the first of which was ADFS.
Jules <jules.richardsonn...@remove.this.gmail.com> wrote: > Hmm, well ADFS is a filesystem format, so surely it's not its job to > know anything about other partitions; an ADFS filesystem just knows > the extent of disk blocks that it may access, and in theory there's > nothing to stop it co-existing with other filesystems on a larger > storage medium.
No, ADFS isn't a file system format :) This is one of the fun elements of RISC OS's VFS; it's up-side-down. ADFS is the device driver. FileCore is the file system format. FileCore just expects a block device; it's up to the driver (ADFS, IDEFS, SCSIFS, etc) to present block devices to it. There is no specification of how to achieve partitions with this (excluding RISC iX, in which you 'partitioned' your hard disc in two by simply lying to HForm about the size, and then using BSD slices in the second half). Which is why all the hardware vendors put the logic in their device driver, instead.
Where, say UNIX, has something like this arrangement: