Prev: Disk performance problem
Next: Mac classic theme for gnome...
From: Johnny B Good on 8 Apr 2010 13:52
The message <hpk7d2$14ca$1(a)energise.enta.net>
from Gordon Henderson <gordon+usenet(a)drogon.net> contains these words:

> In article <OYednSd5GIfuCSDWnZ2dnUVZ8tqdnZ2d(a)bt.com>,
> jasee <jasee(a)btinternet.com> wrote:
> >Gordon Henderson wrote:
> >> In article <q7GdnWnjwv3b4yDWnZ2dnUVZ7vydnZ2d(a)bt.com>,
> >> jasee <jasee(a)btinternet.com> wrote:
> >>> Is the change to the basic sector size by disk manufacturers going
> >>> to effect Linux systems?. It is said that it will effect Windows XP
> >>> and earlier by about 10%. I'm just an occasional Linux user but I'm
> >>> curious.
> >
> >> Well - these disks are already here - no need to wait until 2011.
> >
> >For some manufacturers it seems so, though the official date is 2011, it
> >would have been helpful if they'd clearly identified the drives

> For Western Digital, they're identified with the letters "EARS" in the
> product ID. So the 1.5TB drive is: WD15EARS

> Gordon

It's not just winXP and Linux that are effected, it's also openBSD (as
used by FreeNAS). I bought a couple of WD's 2TB EARS drives last week.
The intention is (possibly, it'll become was) to upgrade two of the 1TB
samsungs (the two non- eco green units out of the four Samsungs fitted)
in my FreeNAS box but I've hit a show stopping issue with these drives.

The whole box crashes when I try to copy (not move, thank goodness!)
the last 100GB or so's worth from the old drive onto its replacement.
This is extremely annoying on account all four drives are then flagged
dirty and FreeNAS refuses to mount any of them until they've been fsck'd
(several hour's worth of fsck runtime to service the lot).

I'd initially done the copying by booting a knoppix live CD session on
the server so I could make sure the new partitions started at sector 64
instead of the default 63 by using fdisk or parted (I forget which one
of those two actually behaved itself in this regard). I created a 1.79
TB Ext2 FS on the partition spaces thus created on the two new disks and
was able to copy the 900 odd GB's worth of data each of the old drives
contained without incident.

Encouragingly, the copying process averaged 64MB/s (frequently peaking
into the 80MB/s region on the larger unfragmented files) which suggested
the sector 64 start point trick had been a success. Unfortunately, after
reassembling the server, just selecting all the files and folders and
clicking on 'properties' from a win2k client was enough to trigger disk
error reports to the FreeNAS console.

Ok, I thought, perhaps I can bypass the issue by wiping the new drives
and starting over, except fit the new drives empty and copy over the
wire(GBit ethernet) from a test bench setup that's destined to upgrade
this 6 year old win2k box I'm using.

Unfortunately, with a claimed 1 hour remaining to complete the copying
process (some 7 hours later), it was halted by a loss of connection. It
turned out that in reducing the remaining space on the target drive down
to 1.02GB FreeNAS had hit a serious problem which crashed it totally,
forcing a reboot.

Now, I have to say, I like FreeNAS despite seeing a similar issue with
the 64 bit version a year or so back on one of the then newly fitted 1TB
Samsungs. Luckily, it wasn't an issue with the 32 bit version.

This time, however, I'm getting just a little cheesed off with such
showstopping behaviour over what should have been anticipated by the
developer(s) as a quite unremarkable and reasonable upgrade of disk
capacity (for gawd's sake, "Storage" is its last name!). Why the hell it
couldn't handle the problem more gracefully than to simply crash I don't
know.

In this case, I think the issue stems from the openBSD developers
rather than the FreeNAS developer(s). I say this on account when I try
to format using the openBSD based tools from within FreeNAS itself, it
knows no better than to undo my fdisk/parted work and set the partition
start point back to sector 63.

What's worse is that when I try to get it to waste as little as 1% of
super user reserved space using an Ext2 format, it then resets it to
5%!. If I abort the format and try using openBSD's own native UFS
format, I do succeed in reducing the waste but it takes several hours
(overnight) to complete and it's quite obvious that writing speed has
suffered a serious hit on performance.

Reading speed, otoh, remains wonderfully fast at almost 64MB/s over the
wire to the test bench setup (having moved on to a version of FreeNAS
that _does_ now permit the attempt to select a jumbo frame size to
actually be set).

My next step is to check out a Knoppix setup on the fileserver box to
see if using a Linux based setup can approach the performance levels of
FreeNAS (it's not for nothing that I chose to use Ext2, rather than
openBSD's "proprietry" UFS system which FreeNAS considers to be its
'native' format on the hard drives).

If this doesn't prove a sufficiently good enough workaround, it looks
as though the planned win2k box upgrade is going to become a lot more
massive than originally intended. One way or another, I'll find a home
for those WD 2TB EARS drives. ;-)

Considering that these EARS drives with their 4096 byte sized sectors
have _actually_ been available for several months now, I'm rather amazed
that the Linux (and openBSD) development community hadn't already gotten
on top of this issue from "Day One" which, afaiaa, was some two years
ago. I mean, just such a minor technicality as this is "Bread and
Butter" stuff to the "Real Programmers"(tm) usually involved with Linux
/ openBSD development work and it would have been a bit of a coup to
have had the jump on the "Dark Empire" in this matter.

Luckily, with Linux, there are at least workarounds to this problem,
unlike the situation that holds with microsoft OSen, especially in the
case of their only decent offering in the form of win2k ( but,
thankfully, the linux partitioning tools are just as effective in
prepping up such drives for ms windows installs as they are for Linux).

--
Regards, John.

Please remove the "ohggcyht" before replying.
The address has been munged to reject Spam-bots.

From: jasee on 8 Apr 2010 14:15

"Johnny B Good" <jcs.computersbutt(a)plugzetnet.co.uk> wrote in message
news:31303030373730364BBE25EA16(a)plugzetnet.co.uk...
> The message <hpk7d2$14ca$1(a)energise.enta.net>
> from Gordon Henderson <gordon+usenet(a)drogon.net> contains these words:
>
>> In article <OYednSd5GIfuCSDWnZ2dnUVZ8tqdnZ2d(a)bt.com>,
>> jasee <jasee(a)btinternet.com> wrote:
>> >Gordon Henderson wrote:
>> >> In article <q7GdnWnjwv3b4yDWnZ2dnUVZ7vydnZ2d(a)bt.com>,
>> >> jasee <jasee(a)btinternet.com> wrote:
>> >>> Is the change to the basic sector size by disk manufacturers going
>> >>> to effect Linux systems?. It is said that it will effect Windows XP
>> >>> and earlier by about 10%. I'm just an occasional Linux user but I'm
>> >>> curious.
>> >
>> >> Well - these disks are already here - no need to wait until 2011.
>> >
>> >For some manufacturers it seems so, though the official date is 2011, it
>> >would have been helpful if they'd clearly identified the drives
>
>> For Western Digital, they're identified with the letters "EARS" in the
>> product ID. So the 1.5TB drive is: WD15EARS
>
>
> It's not just winXP and Linux that are effected, it's also openBSD (as
> used by FreeNAS). I bought a couple of WD's 2TB EARS drives last week.
> The intention is (possibly, it'll become was) to upgrade two of the 1TB
> samsungs (the two non- eco green units out of the four Samsungs fitted)
> in my FreeNAS box but I've hit a show stopping issue with these drives.
>
Snip {tale of woe}
>
> Considering that these EARS drives with their 4096 byte sized sectors
> have _actually_ been available for several months now, I'm rather amazed
> that the Linux (and openBSD) development community hadn't already gotten
> on top of this issue from "Day One" which, afaiaa, was some two years
> ago. I mean, just such a minor technicality as this is "Bread and
> Butter" stuff to the "Real Programmers"(tm) usually involved with Linux
> / openBSD development work and it would have been a bit of a coup to
> have had the jump on the "Dark Empire" in this matter.

I'm amazed that there has been so little press about it. Lots of people are
(myself included) running Xp or earlier. One of the reasons for this is
performance. These disks are really going to hit themv AFAICT, yet there's
very little groundswell. I only just heard about it recently by accident!
I've just bought a terrabyte Hitachi drive and there's no information on
this subject in the data sheet for the drive.


From: Darren Salt on 9 Apr 2010 19:04
I demand that Johnny B Good may or may not have written...

[snip]
> I'd initially done the copying by booting a knoppix live CD session on the
> server so I could make sure the new partitions started at sector 64 instead
> of the default 63 by using fdisk or parted (I forget which one of those two
> actually behaved itself in this regard).

If you've stored a suitable logical geometry in the boot sector, all
partitioning programs should be fine. That said, at least the console-based
ones have switches to set the geometry, so there should be little difficulty
in achieving this.

> I created a 1.79 TB Ext2 FS on the partition spaces thus created on the two
> new disks and was able to copy the 900 odd GB's worth of data each of the
> old drives contained without incident.

With that sort of size, I'd definitely be looking towards ext4 (given a
new-enough kernel). There are some definite speed improvements there...

[snip]
--
| Darren Salt | linux at youmustbejoking | nr. Ashington, | Toon
| using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army
| + This comment has been censored.

"Shhh! The Christians think they are up here alone." - God
From: Darren Salt on 9 Apr 2010 19:18
I demand that jasee may or may not have written...

[snip]
> I'm amazed that there has been so little press about [4K sectors]. Lots of
> people are (myself included) running Xp or earlier. One of the reasons for
> this is performance. These disks are really going to hit themv AFAICT, yet
> there's very little groundswell. I only just heard about it recently by
> accident! I've just bought a terrabyte Hitachi drive and there's no
> information on this subject in the data sheet for the drive.

See what hdparm reports. I have a "1TB" HD here (Hitachi HDS721010CLA332);
the physical sector size is reported as 512 bytes, so I've not worried about
alignment issues.

Also, the release notes for util-linux-ng 2.17 say that fdisk now aligns new
partitions on the minimum IO size boundary (physical sector size, or RAID
stripe chunk size) and copes with HDs with 4K sectors and an alignment offset
for legacy 512-byte sector access (i.e. where the first partition starts at
LBA 63 but the first sector starts at LBA -1, thus ensuring that it's
sector-aligned).

--
| Darren Salt | linux at youmustbejoking | nr. Ashington, | Toon
| using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army
| + http://www.xine-project.org/

"I know what is around the corner. I just don't know where the corner is."
From: Colin Watson on 11 Apr 2010 19:10
jasee <jasee(a)btinternet.com> wrote:
>Is the change to the basic sector size by disk manufacturers going to effect
>Linux systems?. It is said that it will effect Windows XP and earlier by
>about 10%. I'm just an occasional Linux user but I'm curious.

Debian 6.0 (squeeze) and Ubuntu 10.04 LTS should support this properly
during installation; earlier versions of each would use cylinder
alignment instead, and while you could do the partitioning by hand to
work around this it would have been rather tedious. Cylinder alignment
won't generally actually break, but it will be rather slower, probably
by much the same percentage as Windows XP.

(On the flip side, apparently the odd BIOS throws a hissy fit with
non-cylinder alignment, so we can't entirely win here. I plan to make
the old behaviour selectable by booting the installer with the
"partman/alignment=cylinder" option - not ideal but it's probably the
best I can do without throwing an incomprehensible question in
everyone's faces.)

I should publicly thank Western Digital for supplying hardware to help
test the Debian/Ubuntu installer in these situations.

--
Colin Watson [cjwatson(a)chiark.greenend.org.uk]
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Disk performance problem
Next: Mac classic theme for gnome...