|
|
|
|
| Author |
Message |
Michael Baeuerle
Guest
|
 Posted: Fri Jun 01, 2007 2:33 pm Post subject: Re: Quantum XP39100S Atlas II and 8GB limit (not int 13h ext |
 |
|
Michael Baeuerle wrote:
| Quote: |
[changing capacity]
A standard command for this purpose like SET MAX ADDRESS for ATA don't
exist for SCSI (please correct me if this is wrong). So a special tool
for _this_ disk is required ...
|
Correction by myself:
It is possible to use the same optional standard scheme as for changing
the blocksize: You can use MODE SELECT and send a block descriptor with
the "Number of Blocks" field set to the desired value. Now a LL-format
is required to activate the new setting and after that, READ CAPACITY
should return the new capacity.
Micha |
|
| Back to top |
|
 |
Fix your Windows Problems - FAST.
FREE Safe Scan Registry Check. Locate & Fix Errors in Minutes!
|
|
Michael Baeuerle
Guest
|
| Posted: Fri Jun 01, 2007 3:01 pm Post subject: Re: Quantum XP39100S Atlas II and 8GB limit (not int 13h ext |
|
|
da9000 wrote:
| Quote: |
[...]
Now a couple more general questions:
1) I spent hours trying to find out how to get the true max LBA limit
with SCU, but no luck  "show capacity" returns the imposed limit.
Showing the mode pages doesn't have anything either... Anyone know?
|
I haven't found a standard method to read out the maximum supported
number of LBs. As I have written in the other posting, the capacity can
be changed using a block descriptor. You can try to set the new capacity
to 0xFFFFFFFF because the SCSI spec says in SBC2 document chapter
6.3.2.2:
| If the NUMBER OF BLOCKS field is set to a value greater than the
| maximum capacity of the device and less than FFFFFFFFh, then the
| MODE SELECT command shall be terminated with CHECK CONDITION status
| [...]
This means you can try to increase the capacity in intervals, if you get
a CHECK CONDITION you have crossed the "max LBA" boundary. But the
standard has one exception that offers a more easy way:
| If the NUMBER OF BLOCKS field is set to FFFFFFFFh, the logical unit
| shall be set to its maximum capacity.
| [...]
| If the content of the BLOCK LENGTH field is the same as the current
| block length this capacity setting shall take effect on successful
| completion of the MODE SELECT command.
With this method you still cannot read the maximum value but you can
order the disk to use it. I would try someting like:
scu -f /dev/sdx set device capacity 0xFFFFFFFF
A LL-format should not be necessary as long as you don't change the
blocksize too ...
| Quote: | [...]
2) According to the mode pages (and from the noise of this beast),
it's a 7200RPM drive,
|
Yes.
| Quote: | yet doing a low-level format takes 5-6 (maybe
more, not sure, I fell asleep) hours. Isn't this way too slow?
|
No, I have seen format times of several hours on Seagate disks with many
heads too.
| Quote: | 3) After the low-level format is done, and I use dd if=/dev/sda of=/
dev/null bs=16k (Linux, MacOSX, *BSD) to exercise the drive, I only
get 1.1 - 1.5MB/sec. Tad bit low for a 7200RPM drive with 10 (!)
platters and with a FastSCSI card (either 10MB/sec or 20MB/sec
settings without complaints), in synchronus mode, isn't it?
|
Are the values higher if you use more than 16k transfersize?
Micha |
|
| Back to top |
|
|
Michael Baeuerle
Guest
|
| Posted: Fri Jun 01, 2007 4:11 pm Post subject: Folkert vs others (was: Quantum XP39100S Atlas II and 8GB li |
|
|
Folkert Rienstra wrote:
| Quote: |
"da9000" wrote:
You're GOOD!
Yes, I know. Creates quite a bit of envy in this group too.
Baeuerle et all, are you paying attention !? Rob Turk, eat ***.
|
Yes, I'm paying attention but I never tried to be suggestive of you to
be bad. What I don't understand is why you must always be so aggressive.
The other people and I may have less knowledge than you, but we have
never asserted to have more (or being "better"). This is a group for
constructive discussions and not _only_ for ultimate wisdom. We aren't
trolls and we aren't stupid. If we write something wrong, that was not
intended by us, so why don't you simply correct us objectively? I hope
the others are with me when I speak for "us" ...
For my personal defense:
I have e.g. developed a SCSI device from scratch:
http://micha.freeshell.org/pcmcia_drive/index.php
and therefore may safely assert to understand how SCSI is working.
Because of your behaviour you don't have my envy, you have my respect
for your technical competence (that's the difference between subjective
and objective view). To my best knowledge I never have posted something
that was unworthy against you or this group. Because english is not my
native language there may be mistakes in my postings sometimes. But if
you or somebody else was in doubt, I have always tried to explain how it
was meant or taken back a statement that has revealed to be wrong. What
more do you expect - eating *** is no option ...
Micha |
|
| Back to top |
|
|
Folkert Rienstra
Guest
|
| Posted: Wed Jun 06, 2007 3:40 am Post subject: OT: Quantum XP39100S Atlas II and 8GB limit (not int 13h ex |
|
|
"Michael Baeuerle" <michael.baeuerle@stz-e.de> wrote in message news:8bf5j4-o74.ln1@micha.freeshell.org
| Quote: | Folkert Rienstra wrote:
"da9000" wrote:
You're GOOD!
Yes, I know. Creates quite a bit of envy in this group too.
Baeuerle et all, are you paying attention !? Rob Turk, eat ***.
Yes, I'm paying attention
|
No, you don't. You keep ignoring the blatantly obvious.
| Quote: | but I never tried to be suggestive of you to be bad.
|
So this post is about what, singing my praise?
| Quote: | What I don't understand is why you must always be so aggressive.
|
Because I want you on your toes.
| Quote: | The other people and I may have less knowledge than you, but
we have never asserted to have more (or being "better").
|
Yet you babble away like as if you do.
By blatantly ignoring certain facts that shouldn't be ignored it can
only mean that you dismiss them, thereby signalling that you know bet-
ter without saying it as somuch. You say you want to discuss but by
simply ignoring the facts you actually walk away from the discussion.
| Quote: | This is a group for constructive discussions and not _only_ for ultimate
wisdom.
|
Doesn't mean you can just babble away and not be corrected for it.
Doesn't mean you can lie and get away with it because you think no one
will know better than you and you won't get caught. That's quite arrogant.
No? You put my name in the subject title. That's like putting the bait out.
| Quote: | and we aren't stupid.
|
Putting anybodies name in a subject title borders on the terminally stupid.
You box yourself into corners by assuming things that you don't
know and then asserting them as fact without checking it first.
Don't blame me for pointing it out, it 's your own stupid fault.
Blame your own laziness for not checking your facts.
| Quote: | If we write something wrong, that was not intended by us, so why don't
you simply correct us objectively?
|
Because I want you on your toes.
| Quote: | I hope the others are with me when I speak for "us" ...
|
Bummer, looks like they're not.
Ah, isn't it nice to be your own judge.
| Quote: | Because of your behaviour you don't have my envy, you have my respect
|
If I had your respect my name would not be in the subject title.
| Quote: | for your technical competence (that's the difference between subjective
and objective view).
To my best knowledge I never have posted some
thing that was unworthy against you or this group.
|
So you took this opportunity to start?
| Quote: | Because english is not my native language
|
Nor is it for me.
| Quote: | there may be mistakes in my postings sometimes.
|
That's no excuse to have it wrong.
That's no excuse for not proofreading your messages.
| Quote: | But if you or somebody else was in doubt, I have always tried to explain
how it was meant or taken back a statement that has revealed to be wrong.
|
So what's your problem then.
| Quote: | What more do you expect
|
That you stop babbling. I told you that more than once.
And you still do it.
Some people learn from their mistakes, why can't you.
| Quote: | - eating *** is no option ...
|
You can always reconsider.
|
|
| Back to top |
|
|
Folkert Rienstra
Guest
|
| Posted: Wed Jun 06, 2007 3:40 am Post subject: Re: Quantum XP39100S Atlas II and 8GB limit (not int 13h ext |
|
|
"Michael Baeuerle" <michael.baeuerle@stz-e.de> wrote in message news:pn55j4-gs3.ln1@micha.freeshell.org
| Quote: | Michael Baeuerle wrote:
[changing capacity]
A standard command for this purpose like SET MAX ADDRESS for ATA don't
exist for SCSI (please correct me if this is wrong). So a special tool
for _this_ disk is required ...
Correction by myself:
It is possible to use the same
optional
|
Optional?
| Quote: | standard scheme as for changing the blocksize:
|
That's not optional. That's how it's done.
| Quote: | You can use MODE SELECT and send a block descriptor with
the "Number of Blocks" field set to the desired value.
Now a LL-format *is required* to activate the new setting
|
And now you can correct yourself once again:
No, a LL-format is *not* required to activate the new setting.
Once again you have not been paying attention. Once again you
have been ignoring the simple facts that he did it without the
LLF and that none of the apps that I adviced involved using a
Low Level Format.
The facts were staring you right in the face but you had to
deny them again, know better, and insist on a LL-format for
it to succeed, where it's obviously not.
What is wrong with you that you constantly need to spice up
your facts. Everytime it get's you into trouble.
| Quote: | and after that, READ CAPACITY should return the new capacity.
Micha |
|
|
| Back to top |
|
|
Fix your Windows Problems - FAST.
FREE Safe Scan Registry Check. Locate & Fix Errors in Minutes!
|
|
Folkert Rienstra
Guest
|
| Posted: Wed Jun 06, 2007 3:55 am Post subject: Re: Quantum XP39100S Atlas II and 8GB limit (not int 13h ext |
|
|
"Michael Baeuerle" <michael.baeuerle@stz-e.de> wrote in message news:jd75j4-cu3.ln1@micha.freeshell.org
| Quote: | da9000 wrote:
[...]
Now a couple more general questions:
1) I spent hours trying to find out how to get the true max LBA limit
with SCU, but no luck "show capacity" returns the imposed limit.
Showing the mode pages doesn't have anything either... Anyone know?
I haven't found a standard method to read out the maximum supported
number of LBs. As I have written in the other posting, the capacity can
be changed using a block descriptor. You can try to set the new capacity
to 0xFFFFFFFF because the SCSI spec says in SBC2 document chapter
6.3.2.2:
If the NUMBER OF BLOCKS field is set to a value greater than the
maximum capacity of the device and less than FFFFFFFFh, then the MODE
SELECT command shall be terminated with CHECK CONDITION status
[...]
This means you can try to increase the capacity in intervals, if you get
a CHECK CONDITION you have crossed the "max LBA" boundary.
But the standard has one exception that offers a more easy way:
|
It's not an exception, it's an option.
| Quote: |
If the NUMBER OF BLOCKS field is set to FFFFFFFFh,
the logical unit shall be set to its maximum capacity.
[...]
If the content of the BLOCK LENGTH field is the same as the current
block length this capacity setting shall take effect on successful
completion of the MODE SELECT command.
With this method you still cannot read the maximum value
|
Yes, you can. This is what allows you to.
What is doesn't do is show it to you without also setting it.
So you will have to set it back afterwards.
| Quote: | but you can order the disk to use it.
|
And that's why you can. You even said so already in the other post.
| Quote: | I would try someting like:
scu -f /dev/sdx set device capacity 0xFFFFFFFF
A LL-format should not be necessary
|
Period.
| Quote: | as long as you don't change the blocksize too ...
|
And why the hell would you.
Apparently, changing both will make the unit 'Format Corrupted',
until you do a Format Unit. So this is to be strongly avoided.
Unfortunately it doesn't say whether setting the value back to
current blocksize will revert the Format Corrupted state or not.
| Quote: |
[...]
2) According to the mode pages (and from the noise of this beast),
it's a 7200RPM drive,
Yes.
yet doing a low-level format takes 5-6 (maybe more, not sure, I fell
asleep) hours. Isn't this way too slow?
No, I have seen format times of several hours on Seagate disks with many
heads too.
|
Large # of heads has nothing to do with it other than that it makes for a very
large drive and large drives obviously take longer to format than smaller ones.
So capacity divided by throughput decides the time it takes to write it all.
At ~7.5 MB/s avg this drive should (in theory) be able to complete it in
9,100,000,000/7,500,000/60 = ~20 minutes, without verification.
(Of course that's counting on that the drive formats efficiently and is
tracking well).
| Quote: |
3) After the low-level format is done, and I use dd if=/dev/sda of=/
dev/null bs=16k (Linux, MacOSX, *BSD) to exercise the drive, I only
get 1.1 - 1.5MB/sec. Tad bit low for a 7200RPM drive with 10 (!)
platters and with a FastSCSI card (either 10MB/sec or 20MB/sec
settings without complaints), in synchronus mode, isn't it?
Are the values higher if you use more than 16k transfersize?
|
Oops, missed that.
Fortunately 16kB isn't half bad and should still give you about 2/3
(6-7MB/s) of what the drive can do at 64kB or higher transfer lengths.
1-1.5 MB/s is still way below that.
I'm still counting on Cache being disabled. That or physical shock.
|
|
| Back to top |
|
|
Michael Baeuerle
Guest
|
| Posted: Wed Jun 06, 2007 2:07 pm Post subject: Re: Quantum XP39100S Atlas II and 8GB limit (not int 13h ext |
|
|
Folkert Rienstra wrote:
| Quote: |
Michael Baeuerle wrote:
Michael Baeuerle wrote:
[changing capacity]
A standard command for this purpose like SET MAX ADDRESS for ATA don't
exist for SCSI (please correct me if this is wrong). So a special tool
for _this_ disk is required ...
Correction by myself:
It is possible to use the same
optional
[standard method]
Optional?
standard scheme as for changing the blocksize:
That's not optional. That's how it's done.
|
Blockdescriptors even MODE SELECT at all is optional. A standard
compliant disk don't need to support it.
| Quote: | You can use MODE SELECT and send a block descriptor with
the "Number of Blocks" field set to the desired value.
Now a LL-format *is required* to activate the new setting
And now you can correct yourself once again:
No, a LL-format is *not* required to activate the new setting.
|
Correct, the LL-format is only required if the blocksize field in the
blockdescriptor is changed too.
| Quote: | Once again you have not been paying attention. Once again you
have been ignoring the simple facts that he did it without the
LLF and that none of the apps that I adviced involved using a
Low Level Format.
|
If you mean the scu tool: I don't know what he had done because the
documentation don't specify what commands are send and there is no
source code available. Because he had written about the time needed for
LL-format (and because I have already used the blocksize field), I had
assumed unchecked that it is required in general when writing modified
blockdescriptors. My fault ... after reading the spec again I have
posted the details in an other article.
| Quote: | The facts were staring you right in the face but you had to
deny them again, know better, and insist on a LL-format for
it to succeed, where it's obviously not.
|
It is IMHO not obvious.
Micha |
|
| Back to top |
|
|
Michael Baeuerle
Guest
|
| Posted: Wed Jun 06, 2007 2:07 pm Post subject: Re: OT: Quantum XP39100S Atlas II and 8GB limit (not int 13 |
|
|
Folkert Rienstra wrote:
| Quote: |
Michael Baeuerle:
[...]
This is a group for constructive discussions and not _only_ for ultimate
wisdom.
Doesn't mean you can just babble away and not be corrected for it.
|
That's exactly what I wrote: Why not just simple correction.
| Quote: | [...]
We aren't trolls
No? You put my name in the subject title. That's like putting the bait out.
|
I agree, excuse me for this. But I don't take back what I have written.
Micha |
|
| Back to top |
|
|
Michael Baeuerle
Guest
|
| Posted: Wed Jun 06, 2007 2:07 pm Post subject: Re: Quantum XP39100S Atlas II and 8GB limit (not int 13h ext |
|
|
Folkert Rienstra wrote:
| Quote: |
Michael Baeuerle wrote:
da9000 wrote:
A LL-format should not be necessary
Period.
as long as you don't change the blocksize too ...
And why the hell would you.
|
I don't want to do, I only have written what the spec says about.
| Quote: | [...]
2) According to the mode pages (and from the noise of this beast),
it's a 7200RPM drive,
Yes.
yet doing a low-level format takes 5-6 (maybe more, not sure, I fell
asleep) hours. Isn't this way too slow?
No, I have seen format times of several hours on Seagate disks with many
heads too.
Large # of heads has nothing to do with it other than that it makes for a very
large drive and large drives obviously take longer to format than smaller ones.
So capacity divided by throughput decides the time it takes to write it all.
At ~7.5 MB/s avg this drive should (in theory) be able to complete it in
9,100,000,000/7,500,000/60 = ~20 minutes, without verification.
(Of course that's counting on that the drive formats efficiently and is
tracking well).
|
Thats theory. The experience tells that nearly all disks take much
longer to format, >1h is normal even for smaller ones.
I have taken a look in some manuals:
Seagte specify 65 (95 with verify) minutes for the Barracuda 4LP. The
average medium transferrate is 10MByte/s (without seek on one track) ...
in the same region as the Atlas2 in continous mode I think. With your
calculation you get: 4,350,000,000/7,500,000/60 = ~9.6 minutes.
You don't get the correct time even if you use the half
track-transferrate.
Disks with greater # of heads and same capacity should have lower bit
density and therefore lower transferrate. I had expected that this leads
to longer format times. But that seems to be no general rule too: The
Barracuda 4 (22 heads) only needs 40 minutes without verify although it
has slower transferrate and slightly higher capacity than the Barracuda
4LP (10 heads).
| Quote: | 3) After the low-level format is done, and I use dd if=/dev/sda of=/
dev/null bs=16k (Linux, MacOSX, *BSD) to exercise the drive, I only
get 1.1 - 1.5MB/sec. Tad bit low for a 7200RPM drive with 10 (!)
platters and with a FastSCSI card (either 10MB/sec or 20MB/sec
settings without complaints), in synchronus mode, isn't it?
Are the values higher if you use more than 16k transfersize?
Oops, missed that.
Fortunately 16kB isn't half bad and should still give you about 2/3
(6-7MB/s) of what the drive can do at 64kB or higher transfer lengths.
1-1.5 MB/s is still way below that.
|
Ack.
| Quote: | I'm still counting on Cache being disabled. That or physical shock.
|
Physical shock? Do you mean slightly excentered platters so that the
track servo cannot easily hold the heads in place any more and takes
more time to seek?
Micha |
|
| Back to top |
|
|
Folkert Rienstra
Guest
|
| Posted: Thu Jun 07, 2007 3:28 am Post subject: Re: Quantum XP39100S Atlas II and 8GB limit (not int 13h ext |
|
|
"Michael Baeuerle" <michael.baeuerle@stz-e.de> wrote in message news:sveij4-bre.ln1@micha.freeshell.org
| Quote: | Folkert Rienstra wrote:
Michael Baeuerle wrote:
da9000 wrote:
A LL-format should not be necessary
Period.
as long as you don't change the blocksize too ...
And why the hell would you.
I don't want to do,
|
Then don't confuse the issue.
| Quote: | I only have written what the spec says about.
|
Your interpretation of what I believe to be is merely a warning.
| Quote: |
[...]
2) According to the mode pages (and from the noise of this beast),
it's a 7200RPM drive,
Yes.
yet doing a low-level format takes 5-6 (maybe more, not sure, I fell
asleep) hours. Isn't this way too slow?
No, I have seen format times of several hours on Seagate disks with many
heads too.
Large # of heads has nothing to do with it other than that it makes for a very
large drive
and large drives obviously take longer to format than smaller ones.
|
Should have added: within the same model range.
| Quote: | So capacity divided by throughput decides the time it takes to write it all.
At ~7.5 MB/s avg this drive should (in theory) be able to complete it in
9,100,000,000/7,500,000/60 = ~20 minutes, without verification.
(Of course that's counting on that the drive formats efficiently and is
tracking well).
Thats theory. The experience tells that nearly all disks take much
longer to format, > 1h is normal even for smaller ones.
|
That sounds like Formatting time is just a hit and miss afair.
This should be rather exact science.
| Quote: |
I have taken a look in some manuals:
Seagte specify 65 (95 with verify) minutes for the Barracuda 4LP. The
average medium transferrate is 10MByte/s (without seek on one track) ...
in the same region as the Atlas2 in continous mode I think. With your
calculation you get: 4,350,000,000/7,500,000/60 = ~9.6 minutes.
|
Still, even 95 minutes is way less than 5-6 hours.
| Quote: | You don't get the correct time even if you use the half track-transferrate.
|
'half track-transferrate'?
| Quote: |
Disks with greater # of heads and same capacity should have lower bit
density and therefore lower transferrate. I had expected that this leads
to longer format times. But that seems to be no general rule too:
The Barracuda 4 (22 heads) only needs 40 minutes without verify
|
Similar sized beast as the atlas (20 heads) but slower, at half the capacity.
I see my 20 minutes coming nearer and nearer.
| Quote: | although it has slower transferrate and slightly higher capacity than the
Barracuda 4LP (10 heads).
3) After the low-level format is done, and I use dd if=/dev/sda of=/
dev/null bs=16k (Linux, MacOSX, *BSD) to exercise the drive, I only
get 1.1 - 1.5MB/sec. Tad bit low for a 7200RPM drive with 10 (!)
platters and with a FastSCSI card (either 10MB/sec or 20MB/sec
settings without complaints), in synchronus mode, isn't it?
Are the values higher if you use more than 16k transfersize?
Oops, missed that.
Fortunately 16kB isn't half bad and should still give you about 2/3
(6-7MB/s) of what the drive can do at 64kB or higher transfer lengths.
1-1.5 MB/s is still way below that.
Ack.
I'm still counting on Cache being disabled. That or physical shock.
Physical shock? Do you mean slightly
|
Or not so slightly.
| Quote: | excentered platters so that the track servo cannot easily hold the
heads in place any more
and takes more time to seek?
|
I'm thinking more of extensive retries or needing several revs to read
a single track.
|
|
| Back to top |
|
|
Fix your Windows Problems - FAST.
FREE Safe Scan Registry Check. Locate & Fix Errors in Minutes!
|
|
Michael Baeuerle
Guest
|
| Posted: Thu Jun 07, 2007 2:12 pm Post subject: Re: Quantum XP39100S Atlas II and 8GB limit (not int 13h ext |
|
|
Folkert Rienstra wrote:
| Quote: |
Michael Baeuerle wrote:
Folkert Rienstra wrote:
Large # of heads has nothing to do with it other than that it makes for a very
large drive
and large drives obviously take longer to format than smaller ones.
Should have added: within the same model range.
|
Yes, only then it is obvious.
| Quote: | So capacity divided by throughput decides the time it takes to write it all.
At ~7.5 MB/s avg this drive should (in theory) be able to complete it in
9,100,000,000/7,500,000/60 = ~20 minutes, without verification.
(Of course that's counting on that the drive formats efficiently and is
tracking well).
Thats theory. The experience tells that nearly all disks take much
longer to format, > 1h is normal even for smaller ones.
That sounds like Formatting time is just a hit and miss afair.
This should be rather exact science.
|
.... but the details of the formatting process are normally undocumented.
For science you need information.
| Quote: | I have taken a look in some manuals:
Seagte specify 65 (95 with verify) minutes for the Barracuda 4LP. The
average medium transferrate is 10MByte/s (without seek on one track) ...
in the same region as the Atlas2 in continous mode I think. With your
calculation you get: 4,350,000,000/7,500,000/60 = ~9.6 minutes.
Still, even 95 minutes is way less than 5-6 hours.
|
Maybe like this:
This Atlas2 is a 9GByte drive, so you can double the time of the 4LP
with 4GByte (assuming same technology) leading to 190 minutes. The
remaining ~2 hours gap may be due to a slower verify algorithm ...
| Quote: | You don't get the correct time even if you use the half track-transferrate.
'half track-transferrate'?
|
Seagate has specified 10MByte/s "track-transferrate" (when accessing
multiple sectors on the same track with 1:1 interleave). Because
formatting works on the whole disk, the 4LP cannot reach this value
because of seeking and head-switching. The 7.5MByte/s average value you
have used for the Atlas2 is realistic for the 4LP too.
Using 7.5MByte/s leads to the ~10 minutes, using the "half
track-transferrate" (5MByte/s) leads to ~15 minutes. Calculating with
lower values makes no sense because 5MByte/s you can get on the external
interface.
In other words: Your calculation cannot explain (for this disk) why the
formatting take 4 times longer in reality.
| Quote: | Disks with greater # of heads and same capacity should have lower bit
density and therefore lower transferrate. I had expected that this leads
to longer format times. But that seems to be no general rule too:
The Barracuda 4 (22 heads) only needs 40 minutes without verify
Similar sized beast as the atlas (20 heads) but slower, at half the capacity.
|
Because of the many platters, Seagate had no space left for the mounting
screws in the middle ... therefore a bit difficult to mount into the
case. But very reliable (with good airflow).
| Quote: | I see my 20 minutes coming nearer and nearer.
|
You surely find one that really have 20 minutes, but even slower as the
4LP you will find too. IMHO there can be no single "format time" formula
for all disks.
Micha |
|
| Back to top |
|
|
|
|
| |
Watched Topics
Search
Register
Log in to check your private messages
Profile
Log in
Memberlist
Usergroups