Re: [zfs-discuss] Can we get some documentation on iSCSI sharing after comstar took over?

[Erik Ableson]

Certainly! I just whipped that up since I was testing out a pile of  
clients with different volumes and got tired of going through all the  
steps so anything to make it more complete would be useful.


Cordialement,

Erik Ableson

+33.6.80.83.58.28
Envoyé depuis mon iPhone

On 17 mars 2010, at 00:25, Svein Skogen  wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16.03.2010 22:31, erik.ableson wrote:


On 16 mars 2010, at 21:00, Marc Nicholas wrote:

On Tue, Mar 16, 2010 at 3:16 PM, Svein Skogen mailto:sv...@stillbilde.net>> wrote:



I'll write you a Perl script :)


   I think there are ... several people that'd like a script that  
gave us
   back some of the ease of the old shareiscsi one-off, instead of  
having

   to spend time on copy-and-pasting GUIDs they have ... no real use
   for. ;)


I'll try and knock something up in the next few days, then!


Try this :

http://www.infrageeks.com/groups/infrageeks/wiki/56503/ 
zvol2iscsi.html




Thank you! :)

Mind if I (after some sleep) look at extending your script a little?  
Of

course with feedback of the changes I make?

//Svein

- --
- +---+---
 /"\   |Svein Skogen   | sv...@d80.iso100.no
 \ /   |Solberg Østli 9| PGP Key:  0xE5E76831
  X|2020 Skedsmokorset | sv...@jernhuset.no
 / \   |Norway | PGP Key:  0xCE96CE13
   |   | sv...@stillbilde.net
ascii  |   | PGP Key:  0x58CD33B6
ribbon |System Admin   | svein-listm...@stillbilde.net
Campaign|stillbilde.net | PGP Key:  0x22D494A4
   +---+---
   |msn messenger: | Mobile Phone: +47 907 03 575
   |sv...@jernhuset.no | RIPE handle:SS16503-RIPE
- +---+---
If you really are in a hurry, mail me at
  svein-mob...@stillbilde.net
This mailbox goes directly to my cellphone and is checked
   even when I'm not in front of my computer.
- 
Picture Gallery:
 https://gallery.stillbilde.net/v/svein/
- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkugE3wACgkQSBMQn1jNM7YtcwCdFHWdZ2nGSMCsiSEbf9jh+YLT
S8YAoOErsJWEkUYSKFiJ/tINxU0gLWHn
=OAds
-END PGP SIGNATURE-

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Posible newbie question about space between zpool and zfs file systems

[Erik Trimble]

On 3/16/2010 8:29 PM, David Dyer-Bennet wrote:

On 3/16/2010 17:45, Erik Trimble wrote:

David Dyer-Bennet wrote:

On Tue, March 16, 2010 14:59, Erik Trimble wrote:


Has there been a consideration by anyone to do a class-action lawsuit
for false advertising on this?  I know they now have to include the 
"1GB

= 1,000,000,000 bytes" thing in their specs and somewhere on the box,
but just because I say "1 L = 0.9 metric liters" somewhere on the box,
it shouldn't mean that I should be able to avertise in huge letters 
"2 L

bottle of Coke" on the outside of the package...


I think "giga" is formally defined as a prefix meaning 10^9; that 
is, the
definition the disk manufacturers are using is the standard metric 
one and

very probably the one most people expect.  There are international
standards for these things.

I'm well aware of the history of power-of-two block and disk sizes in
computers (the first computers I worked with pre-dated that period); 
but I

think we need to recognize that this is our own weird local usage of
terminology, and that we can't expect the rest of the world to 
change to

our way of doing things.


That's RetConn-ing.  The only reason the stupid GiB / GB thing came 
around in the past couple of years is that the disk drive 
manufacturers pushed SI to do it.
Up until 5 years ago (or so), GigaByte meant a power of 2 to 
EVERYONE, not just us techies.   I would hardly call 40+ years of 
using the various giga/mega/kilo  prefixes as a power of 2 in 
computer science as non-authoritative.  In fact, I would argue that 
the HD manufacturers don't have a leg to stand on - it's not like 
they were "outside" the field and used to the "standard" SI notation 
of powers of 10.  Nope. They're inside the industry, used the 
powers-of-2 for decades, then suddenly decided to "modify" that 
meaning, as it served their marketing purposes.


The SI meaning was first proposed in the 1920s, so far as I can tell.  
Our entire history of special usage took place while the SI definition 
was in place.  We simply mis-used it.  There was at the time no prefix 
for what we actually wanted (not giga then, but mega), so we borrowed 
and repurposed mega.


Doesn't matter whether the "original" meaning of K/M/G was a 
power-of-10.  What matters is internal usage in the industry.  And that 
has been consistent with powers-of-2 for 40+ years.  There has been NO 
outside understanding that GB = 1 billion bytes until the Storage 
Industry decided it wanted it that way.  That's pretty much the 
definition of distorted advertising.


The issue here is getting what you paid for.  Changing the meaning of a 
well-understood term to be something that NO ONE else has used in that 
context is pretty much the definition of false advertising.


Put it another way:  for all those folks in the UK, how would you like 
to buy a Hundredweight (cwt) of something, but only get 100 lbs actually 
delivered?  The UK (Imperial) cwt = 112 lbs, while the US cwt = 100 
lbs.   Having some fine print on the package that said cwt=100lbs isn't 
going to fly with the British Advertising Board.  So why should we allow 
the fine print of 1
 GB = 1 billion bytes?  It's the same redefinition of a common term to 
confuse and distort.



I know what you mean about the disk manufacturers changing.  And I'm 
sure they did it because it made their disks sound bigger for free, 
and that's clearly a marketing choice, and yes, it creates the problem 
that when the software reports the size it often doesn't agree with 
the manufacturer size.  I just can't get up a good head of steam about 
this when they're using the prefix correctly and we're not, though.


Problem is, they're NOT using it correctly.  Language is domain-specific 
- that is, terms have context.  A word can mean completely different 
things in different contexts, and it's not correct to say X = true 
meaning for a given word.  In this case, historical usage PLUS /actual/ 
implementation usage indicates that K/M/G/T are powers of 2.  In our 
context of computing, they've meant powers-of-2.  It's also disingenuous 
for them to argue that "consumers" (i.e. non-technical people) didn't 
understand the usage of powers-of-2.  To effectively argue that, they've 
have to have made the switch around the time that mass-consumer 
usage/retailing of computing was happening, which was (at best) 1990.  
Oops. 15 years later it isn't rational to argue that consumers don't 
understand the "technical" usage of the term.


Bottom line is that it's a advertising scam. Promising one thing, and 
delivering another. That's what the truth-in-advertising laws are for.


--
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Posible newbie question about space between zpool and zfs file systems

[Erik Trimble]

On 3/16/2010 4:23 PM, Roland Rambau wrote:

Eric,

careful:

Am 16.03.2010 23:45, schrieb Erik Trimble:


Up until 5 years ago (or so), GigaByte meant a power of 2 to EVERYONE,
not just us techies. I would hardly call 40+ years of using the various
giga/mega/kilo prefixes as a power of 2 in computer science as
non-authoritative.


How long does it take to transmit 1 TiB over a 1 GB/sec tranmission
link, assuming no overhead ?

See ?

  hth

  -- Roland



I guess folks have gotten lazy all over.

Actually, for networking, it's all "GigaBIT", but I get your meaning. 
Which is why it's all properly labeled "1Gb" Ethernet, not "1GB" ethernet.


That said, I'm still under the impression that Giga = 1024^3 for 
networking, just like Mega = 1024^2.  After all, it's 100Mbit Ethernet, 
which doesn't mean it runs at 100Mhz.


That is, on Fast Ethernet, I should be sending a max 100 x 1024^2 BITS 
per second.



Data amounts are (so far as I know universally) employing powers-of-2, 
while frequencies are done in powers-of-10. Thus, baud (for modems) is 
in powers-of-10, as are CPU/memory speeds.  Memory (*RAM of all sorts), 
bus THROUGHPUT (i.e. PCI-E is in powers-of-2), networking throughput, 
and even graphics throughput is in powers-of-2.


If they want to use powers-of-10, then use the actual "normal" names, 
like graphics performance ratings have done (i.e. 10 billion texels, not 
"10 Gigatexels".   Take a look at Nvidia's product literature:


http://www.nvidia.com/object/IO_11761.html


It's just the storage vendors using the broken measurements. Bastards!



--
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Posible newbie question about space between zpool and zfs file systems

[David Dyer-Bennet]

On 3/16/2010 17:45, Erik Trimble wrote:

David Dyer-Bennet wrote:

On Tue, March 16, 2010 14:59, Erik Trimble wrote:


Has there been a consideration by anyone to do a class-action lawsuit
for false advertising on this?  I know they now have to include the 
"1GB

= 1,000,000,000 bytes" thing in their specs and somewhere on the box,
but just because I say "1 L = 0.9 metric liters" somewhere on the box,
it shouldn't mean that I should be able to avertise in huge letters 
"2 L

bottle of Coke" on the outside of the package...


I think "giga" is formally defined as a prefix meaning 10^9; that is, 
the
definition the disk manufacturers are using is the standard metric 
one and

very probably the one most people expect.  There are international
standards for these things.

I'm well aware of the history of power-of-two block and disk sizes in
computers (the first computers I worked with pre-dated that period); 
but I

think we need to recognize that this is our own weird local usage of
terminology, and that we can't expect the rest of the world to change to
our way of doing things.


That's RetConn-ing.  The only reason the stupid GiB / GB thing came 
around in the past couple of years is that the disk drive 
manufacturers pushed SI to do it.
Up until 5 years ago (or so), GigaByte meant a power of 2 to EVERYONE, 
not just us techies.   I would hardly call 40+ years of using the 
various giga/mega/kilo  prefixes as a power of 2 in computer science 
as non-authoritative.  In fact, I would argue that the HD 
manufacturers don't have a leg to stand on - it's not like they were 
"outside" the field and used to the "standard" SI notation of powers 
of 10.  Nope. They're inside the industry, used the powers-of-2 for 
decades, then suddenly decided to "modify" that meaning, as it served 
their marketing purposes.


The SI meaning was first proposed in the 1920s, so far as I can tell.  
Our entire history of special usage took place while the SI definition 
was in place.  We simply mis-used it.  There was at the time no prefix 
for what we actually wanted (not giga then, but mega), so we borrowed 
and repurposed mega.


I know what you mean about the disk manufacturers changing.  And I'm 
sure they did it because it made their disks sound bigger for free, and 
that's clearly a marketing choice, and yes, it creates the problem that 
when the software reports the size it often doesn't agree with the 
manufacturer size.  I just can't get up a good head of steam about this 
when they're using the prefix correctly and we're not, though.


--

David Dyer-Bennet, d...@dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] How to manage scrub priority or defer scrub?

[Tonmaus]

> Are you sure that you didn't also enable
> something which 
> does consume lots of CPU such as enabling some sort
> of compression, 
> sha256 checksums, or deduplication?

None of them is active on that pool or in any existing file system. Maybe the 
issue is particular to RAIDZ2, which is comparably recent. On that occasion: 
does anybody know if ZFS reads all parities during a scrub? Wouldn't it be 
sufficient for stale corruption detection to read only one parity set unless an 
error occurs there?

> The main concern that one should have is I/O
> bandwidth rather than CPU 
> consumption since "software" based RAID must handle
> the work using the 
> system's CPU rather than expecting it to be done by
> some other CPU. 
> There are more I/Os and (in the case of mirroring)
> more data 
> transferred.

What I am trying to say is that CPU may become the bottleneck for I/O in case 
of parity-secured stripe sets. Mirrors and simple stripe sets have almost 0 
impact on CPU. So far at least my observations. Moreover, x86 processors not 
optimized for that kind of work as much as i.e. an Areca controller with a 
dedicated XOR chip is, in its targeted field.

Regards,

Tonmaus
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Can we get some documentation on iSCSI sharing after comstar took over?

[Svein Skogen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16.03.2010 22:31, erik.ableson wrote:
> 
> On 16 mars 2010, at 21:00, Marc Nicholas wrote:
>> On Tue, Mar 16, 2010 at 3:16 PM, Svein Skogen > > wrote:
>>
>>
>> > I'll write you a Perl script :)
>>
>> I think there are ... several people that'd like a script that gave us
>> back some of the ease of the old shareiscsi one-off, instead of having
>> to spend time on copy-and-pasting GUIDs they have ... no real use
>> for. ;)
>>
>>
>> I'll try and knock something up in the next few days, then!
> 
> Try this :
> 
> http://www.infrageeks.com/groups/infrageeks/wiki/56503/zvol2iscsi.html
> 

Thank you! :)

Mind if I (after some sleep) look at extending your script a little? Of
course with feedback of the changes I make?

//Svein

- -- 
- +---+---
  /"\   |Svein Skogen   | sv...@d80.iso100.no
  \ /   |Solberg Østli 9| PGP Key:  0xE5E76831
   X|2020 Skedsmokorset | sv...@jernhuset.no
  / \   |Norway | PGP Key:  0xCE96CE13
|   | sv...@stillbilde.net
 ascii  |   | PGP Key:  0x58CD33B6
 ribbon |System Admin   | svein-listm...@stillbilde.net
Campaign|stillbilde.net | PGP Key:  0x22D494A4
+---+---
|msn messenger: | Mobile Phone: +47 907 03 575
|sv...@jernhuset.no | RIPE handle:SS16503-RIPE
- +---+---
 If you really are in a hurry, mail me at
   svein-mob...@stillbilde.net
 This mailbox goes directly to my cellphone and is checked
even when I'm not in front of my computer.
- 
 Picture Gallery:
  https://gallery.stillbilde.net/v/svein/
- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkugE3wACgkQSBMQn1jNM7YtcwCdFHWdZ2nGSMCsiSEbf9jh+YLT
S8YAoOErsJWEkUYSKFiJ/tINxU0gLWHn
=OAds
-END PGP SIGNATURE-
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Posible newbie question about space between zpool and zfs file systems

[Roland Rambau]

Eric,

careful:

Am 16.03.2010 23:45, schrieb Erik Trimble:


Up until 5 years ago (or so), GigaByte meant a power of 2 to EVERYONE,
not just us techies. I would hardly call 40+ years of using the various
giga/mega/kilo prefixes as a power of 2 in computer science as
non-authoritative.


How long does it take to transmit 1 TiB over a 1 GB/sec tranmission
link, assuming no overhead ?

See ?

  hth

  -- Roland



--


Roland Rambau Server and Solution Architects
Principal Field Technologist  Global Systems Engineering
Phone: +49-89-46008-2520  Mobile:+49-172-84 58 129
Fax:   +49-89-46008-  mailto:roland.ram...@sun.com

Sitz der Gesellschaft: Sun Microsystems GmbH,
Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht München: HRB 161028;
Geschäftsführer: Thomas Schröder
*** UNIX ** /bin/sh * FORTRAN **
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Posible newbie question about space between zpool and zfs file systems

[Tonmaus]

The reason why there is not more uproar is that cost per data unit is dwindling 
while the gap resulting from this marketing trick is increasing. I remember a 
case a German broadcaster filed against a system integrator in the age of the 4 
GB SCSI drive. This was in the mid-90s.

Regards,

Tonmaus
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Posible newbie question about space between zpool and zfs file systems

[Edho P Arief]

On Wed, Mar 17, 2010 at 5:45 AM, Erik Trimble  wrote:
> Up until 5 years ago (or so), GigaByte meant a power of 2 to EVERYONE, not
> just us techies.   I would hardly call 40+ years of using the various
> giga/mega/kilo  prefixes as a power of 2 in computer science as
> non-authoritative.  In fact, I would argue that the HD manufacturers don't
> have a leg to stand on - it's not like they were "outside" the field and
> used to the "standard" SI notation of powers of 10.  Nope. They're inside
> the industry, used the powers-of-2 for decades, then suddenly decided to
> "modify" that meaning, as it served their marketing purposes.
>

it's probably just me, but I always raged when calculating anything
using imperial units, * binary bytes and time.

-- 
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Posible newbie question about space between zpool and zfs file systems

[Erik Trimble]

Erik Trimble wrote:

Tonmaus wrote:

Has there been a consideration by anyone to do a
class-action lawsuit for false advertising on this?  I know they now 
have

to include the "1GB = 1,000,000,000 bytes" thing in their specs and
somewhere on the box, but just because I say "1 L = 0.9 metric liters"
somewhere on the box, it shouldn't mean that I should be able to 
avertise

in huge letters "2 L bottle of Coke" on the outside of the package...



If I am not completely mistaken, 1^n/1,024^n is converging against 0 
for n vs infinite. That is certainly an unwarranted facilitation of 
Kryder's law for very large storage devices.


Regards,

Tonmaus
  
well, that's true, even if it is Limit n->infinity for [1000^n  / 
1024^n]it's still 0.  :-)



Actually, my old Calculus teacher would be disappointed in me.

It's  Lim n->infinity ( 1000^n / (2^10)^n)

or:
  Lim n->infinity (1000^n / 2^10n)


As Tonmaus pointed out, it all still trends to 0. 



Now that little bit of pedantic anal calculus-izing is over, back to our 
regularly schedule madness.



--
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] How to manage scrub priority or defer scrub?

[Bob Friesenhahn]

On Tue, 16 Mar 2010, Tonmaus wrote:

AFAICS the CPU loads are only high while scrubbing a double parity 
pool. I have no indication of a technical misbehaviour with the 
exception of dismal concurrent performance.


This seems pretty weird to me.  I have not heard anyone else complain 
about this sort of problem before in the several years I have been on 
this list.  Are you sure that you didn't also enable something which 
does consume lots of CPU such as enabling some sort of compression, 
sha256 checksums, or deduplication?


running from currently. I am seeing CPU performance being a pain 
point on any "software" based array I have used so far. From SOHO 
NAS boxes (the usual Thecus stuff) to NetApp 3200 filers, all 
exposed a nominal performance drop once parity configurations were 
employed.


The main concern that one should have is I/O bandwidth rather than CPU 
consumption since "software" based RAID must handle the work using the 
system's CPU rather than expecting it to be done by some other CPU. 
There are more I/Os and (in the case of mirroring) more data 
transferred.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Posible newbie question about space between zpool and zfs file systems

[Erik Trimble]

Tonmaus wrote:

Has there been a consideration by anyone to do a
class-action lawsuit 
for false advertising on this?  I know they now have
to include the "1GB 
= 1,000,000,000 bytes" thing in their specs and
somewhere on the box, 
but just because I say "1 L = 0.9 metric liters"
somewhere on the box, 
it shouldn't mean that I should be able to avertise
in huge letters "2 L 
bottle of Coke" on the outside of the package...



If I am not completely mistaken, 1^n/1,024^n is converging against 0 for n vs 
infinite. That is certainly an unwarranted facilitation of Kryder's law for 
very large storage devices.

Regards,

Tonmaus
  
well, that's true, even if it is Limit n->infinity for [1000^n  / 
1024^n]it's still 0.  :-)


But seriously, you lose 2.3% per prefix.  Right now, we're up to almost 
a 10% difference at TB.  In 10 years for Petabyte, we're at over 11% 
loss.  In 20 years, when Exabyte drives (or whatever storage is on) are 
common, that's almost 15% loss.


Frankly, I'm starting to see an analog with Nautical Miles vs Statue Miles.

--
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Posible newbie question about space between zpool and zfs file systems

[Erik Trimble]

David Dyer-Bennet wrote:

On Tue, March 16, 2010 14:59, Erik Trimble wrote:

  

Has there been a consideration by anyone to do a class-action lawsuit
for false advertising on this?  I know they now have to include the "1GB
= 1,000,000,000 bytes" thing in their specs and somewhere on the box,
but just because I say "1 L = 0.9 metric liters" somewhere on the box,
it shouldn't mean that I should be able to avertise in huge letters "2 L
bottle of Coke" on the outside of the package...



I think "giga" is formally defined as a prefix meaning 10^9; that is, the
definition the disk manufacturers are using is the standard metric one and
very probably the one most people expect.  There are international
standards for these things.

I'm well aware of the history of power-of-two block and disk sizes in
computers (the first computers I worked with pre-dated that period); but I
think we need to recognize that this is our own weird local usage of
terminology, and that we can't expect the rest of the world to change to
our way of doing things.
  


That's RetConn-ing.  The only reason the stupid GiB / GB thing came 
around in the past couple of years is that the disk drive manufacturers 
pushed SI to do it. 

Up until 5 years ago (or so), GigaByte meant a power of 2 to EVERYONE, 
not just us techies.   I would hardly call 40+ years of using the 
various giga/mega/kilo  prefixes as a power of 2 in computer science as 
non-authoritative.  In fact, I would argue that the HD manufacturers 
don't have a leg to stand on - it's not like they were "outside" the 
field and used to the "standard" SI notation of powers of 10.  Nope. 
They're inside the industry, used the powers-of-2 for decades, then 
suddenly decided to "modify" that meaning, as it served their marketing 
purposes.


Note that NOBODY else in the computer industry does this in their 
marketing materials - if it's such a standard, why on earth don't the 
DRAM chip makers support (and market) it that way?   The various Mhz/Ghz 
notations are powers-of-10, but they've always been that way, and more 
importantly, are defined by the OSes and other software as being that 
way.  HD capacities are an anomaly,  and it's purely marketing smooze. 


They should get smacked hard again on this.

It would be one thing if it was never seen (or only by super-nerds like 
us), but for the average consumer, when they buy that nice shiny Dell 
with an advertised 1TB disk, then boot to Windows 7, why does Windows 
then say that their C drive is only 900GB in size?   How is that /not/ 
deceptive marketing?



--
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] Problem importing a pool consisting of mkfile elements

[Marlanne DeLaSource]

Hi,

When creating a zfs pool with mkfile components in S10 10/09, I was testing the 
export/import feature (I did it in Solaris 11/06 and it worked well).

But it didn't work. I tried the -d /dir option without success.
It didn't work any better with the zpool destroy and zpool import -D succession 
of events.

Is is a removed feature ? I know that it's better to work with whole disks.

By the way. Is there a way to move the files to another system and try to 
import them on the target system ? (I guess this is no :-))

Thanks for your answer.
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] How to manage scrub priority or defer scrub?

[Tonmaus]

> If CPU is maxed out then that usually indicates some
> severe problem 
> with choice of hardware or a misbehaving device
> driver.  Modern 
> systems have an abundance of CPU.

AFAICS the CPU loads are only high while scrubbing a double parity pool. I have 
no indication of a technical misbehaviour with the exception of dismal 
concurrent performance.

What is not getting beyond me is the notion that even if I *had* a storage 
configuration with 20 times more I/O capacity it still would max out any CPU I 
could buy better than the single L5410 I am running from currently. I am seeing 
CPU performance being a pain point on any "software" based array I have used so 
far. From SOHO NAS boxes (the usual Thecus stuff) to NetApp 3200 filers, all 
exposed a nominal performance drop once parity configurations were employed.
Performance of the L5410 is abundant for the typical operation of my system, 
btw. It can easiely saturate the dual 1000 Mbit NICs for iSCSI and CIFS 
services. I am slightly reluctant to buy a second L5410 just to provide more 
headroom during maintenance operations, as the device will be idle otherwise, 
consuming power.

Regards,

Tonmaus
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Can we get some documentation on iSCSI sharing after comstar took over?

[erik.ableson]

On 16 mars 2010, at 21:00, Marc Nicholas wrote:
> On Tue, Mar 16, 2010 at 3:16 PM, Svein Skogen  wrote:
> 
> > I'll write you a Perl script :)
> 
> I think there are ... several people that'd like a script that gave us
> back some of the ease of the old shareiscsi one-off, instead of having
> to spend time on copy-and-pasting GUIDs they have ... no real use for. ;)
> 
> 
> I'll try and knock something up in the next few days, then!

Try this :

http://www.infrageeks.com/groups/infrageeks/wiki/56503/zvol2iscsi.html

Cheers,

Erik

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] How to manage scrub priority or defer scrub?

[Tonmaus]

Hello,

> In following this discussion, I get the feeling that
> you and Richard are somewhat talking past each
> other.

Talking past each other is a problem I have noted and remarked earlier. I have 
to admit to have got frustrated about the discussion narrowing down to a 
certain perspective that was quite the opposite of my own observations and what 
I had initially described. It may be that I have been more harsh than I should. 
Please accept my apology.
I was trying from the outset to obtain a perspective on the matter that is 
independent from an actual configuration. I firmly believe that the scrub 
function is more meaningful if it can be applied in a variety of 
implementations.
I think however that the insight that there seems to be no specific scrub 
management functions is transferable from a commodity implementation to a 
enterprise configuration.

Regards,

Tonmaus
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Posible newbie question about space between zpool and zfs file systems

[Tonmaus]

> Has there been a consideration by anyone to do a
> class-action lawsuit 
> for false advertising on this?  I know they now have
> to include the "1GB 
> = 1,000,000,000 bytes" thing in their specs and
> somewhere on the box, 
> but just because I say "1 L = 0.9 metric liters"
> somewhere on the box, 
> it shouldn't mean that I should be able to avertise
> in huge letters "2 L 
> bottle of Coke" on the outside of the package...

If I am not completely mistaken, 1^n/1,024^n is converging against 0 for n vs 
infinite. That is certainly an unwarranted facilitation of Kryder's law for 
very large storage devices.

Regards,

Tonmaus
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Posible newbie question about space between zpool and zfs file systems

[David Dyer-Bennet]

On Tue, March 16, 2010 14:59, Erik Trimble wrote:

>
> Has there been a consideration by anyone to do a class-action lawsuit
> for false advertising on this?  I know they now have to include the "1GB
> = 1,000,000,000 bytes" thing in their specs and somewhere on the box,
> but just because I say "1 L = 0.9 metric liters" somewhere on the box,
> it shouldn't mean that I should be able to avertise in huge letters "2 L
> bottle of Coke" on the outside of the package...

I think "giga" is formally defined as a prefix meaning 10^9; that is, the
definition the disk manufacturers are using is the standard metric one and
very probably the one most people expect.  There are international
standards for these things.

I'm well aware of the history of power-of-two block and disk sizes in
computers (the first computers I worked with pre-dated that period); but I
think we need to recognize that this is our own weird local usage of
terminology, and that we can't expect the rest of the world to change to
our way of doing things.

-- 
David Dyer-Bennet, d...@dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Can we get some documentation on iSCSI sharing after comstar took over?

[Marc Nicholas]

On Tue, Mar 16, 2010 at 3:16 PM, Svein Skogen  wrote:

>
> > I'll write you a Perl script :)
> >
>
> I think there are ... several people that'd like a script that gave us
> back some of the ease of the old shareiscsi one-off, instead of having
> to spend time on copy-and-pasting GUIDs they have ... no real use for. ;)
>
>
I'll try and knock something up in the next few days, then!

-marc
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Posible newbie question about space between zpool and zfs file systems

[Erik Trimble]

Carson Gaspar wrote:
Not quite. 
11 x 10^12 =~ 10.004 x (1024^4).


So, the 'zpool list' is right on, at "10T" available.


Duh, I was doing GiB math (y = x * 10^9 / 2^20), not TiB math (y = x * 
10^12 / 2^40).


Thanks for the correction.


You're welcome. :-)


On a not-completely-on-topic note:

Has there been a consideration by anyone to do a class-action lawsuit 
for false advertising on this?  I know they now have to include the "1GB 
= 1,000,000,000 bytes" thing in their specs and somewhere on the box, 
but just because I say "1 L = 0.9 metric liters" somewhere on the box, 
it shouldn't mean that I should be able to avertise in huge letters "2 L 
bottle of Coke" on the outside of the package...





--
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Can we get some documentation on iSCSI sharing after comstar took over?

[Svein Skogen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16.03.2010 19:57, Marc Nicholas wrote:
> 
> 
> On Tue, Mar 16, 2010 at 2:46 PM, Svein Skogen  > wrote:
> 
> 
> > Not quite a one liner. After you create the target once (step 3),
> you do not have to do that again for the next volume. So three lines.
> 
> 
> So ... no way around messing with guid numbers?
> 
> 
> I'll write you a Perl script :)
> 

I think there are ... several people that'd like a script that gave us
back some of the ease of the old shareiscsi one-off, instead of having
to spend time on copy-and-pasting GUIDs they have ... no real use for. ;)

//Svein

- -- 
- +---+---
  /"\   |Svein Skogen   | sv...@d80.iso100.no
  \ /   |Solberg Østli 9| PGP Key:  0xE5E76831
   X|2020 Skedsmokorset | sv...@jernhuset.no
  / \   |Norway | PGP Key:  0xCE96CE13
|   | sv...@stillbilde.net
 ascii  |   | PGP Key:  0x58CD33B6
 ribbon |System Admin   | svein-listm...@stillbilde.net
Campaign|stillbilde.net | PGP Key:  0x22D494A4
+---+---
|msn messenger: | Mobile Phone: +47 907 03 575
|sv...@jernhuset.no | RIPE handle:SS16503-RIPE
- +---+---
 If you really are in a hurry, mail me at
   svein-mob...@stillbilde.net
 This mailbox goes directly to my cellphone and is checked
even when I'm not in front of my computer.
- 
 Picture Gallery:
  https://gallery.stillbilde.net/v/svein/
- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuf2Q0ACgkQSBMQn1jNM7arOgCgnSIiTZOLhM6jRrh+l2gl1zcn
CrYAoIYIgEPh82tD9gaEixlDQ4SigXUc
=ppBc
-END PGP SIGNATURE-
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Can we get some documentation on iSCSI sharing after comstar took over?

[Marc Nicholas]

On Tue, Mar 16, 2010 at 2:46 PM, Svein Skogen  wrote:

>
> > Not quite a one liner. After you create the target once (step 3), you do
> not have to do that again for the next volume. So three lines.
>
>
> So ... no way around messing with guid numbers?
>
>
I'll write you a Perl script :)

-marc
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] dedupratio riddle

[valrh...@gmail.com]

Someone correct me if I'm wrong, but it could just be a coincidence. That is, 
perhaps the data that you copied happens to lead to a dedup ratio relative to 
the data that's already on there. You could test this out by copying a few 
gigabytes of data you know is unique (like maybe a DVD video file or 
something), and that should change the dedup ratio.
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Can we get some documentation on iSCSI sharing after comstar took over?

[Svein Skogen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16.03.2010 19:42, Scott Meilicke wrote:
> This is what I used:
> http://wikis.sun.com/display/OpenSolarisInfo200906/How+to+Configure+iSCSI+Target+Ports
> 
> I distilled that to:
> 
> disable the old, enable the new (comstar)
> 
> * sudo svcadm disable iscsitgt
> * sudo svcadm enable stmf
> 
> Then four steps (using my zfs/zpool info - substitute for yours):
> 
> * sudo zfs create -s -V 5t data01/san/gallardo/g (the -s makes it thin, -V 
> specifies a block volume)
> * sbdadm create-lu /dev/zvol/rdsk/data01/san/gallardo/g
> * sudo itadm create-target
> * sudo stmfadm add-view 600144F0E24785004A80910A0001
> 
> This should allow any initiator to connect to your volume, no security.
> 
> Not quite a one liner. After you create the target once (step 3), you do not 
> have to do that again for the next volume. So three lines.

So ... no way around messing with guid numbers?

That's what I was afraid of.

Well, comstar may have a lot of features, but the one major feature the
legacy target had (it was simple to use for non-paid-by-the-hour san
admins) is gone.

Thanks a lot. ;)

//Svein

- -- 
- +---+---
  /"\   |Svein Skogen   | sv...@d80.iso100.no
  \ /   |Solberg Østli 9| PGP Key:  0xE5E76831
   X|2020 Skedsmokorset | sv...@jernhuset.no
  / \   |Norway | PGP Key:  0xCE96CE13
|   | sv...@stillbilde.net
 ascii  |   | PGP Key:  0x58CD33B6
 ribbon |System Admin   | svein-listm...@stillbilde.net
Campaign|stillbilde.net | PGP Key:  0x22D494A4
+---+---
|msn messenger: | Mobile Phone: +47 907 03 575
|sv...@jernhuset.no | RIPE handle:SS16503-RIPE
- +---+---
 If you really are in a hurry, mail me at
   svein-mob...@stillbilde.net
 This mailbox goes directly to my cellphone and is checked
even when I'm not in front of my computer.
- 
 Picture Gallery:
  https://gallery.stillbilde.net/v/svein/
- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuf0fUACgkQSBMQn1jNM7atHQCg7OEtdxlXG/jfaR865g5nq8w3
UfsAoJDuVcLgyTwq++hujCh5S0Vb+lWp
=1JHV
-END PGP SIGNATURE-
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Can we get some documentation on iSCSI sharing after comstar took over?

[Brandon High]

On Tue, Mar 16, 2010 at 6:40 PM, Cindy Swearingen
 wrote:
> Here's a couple of pointers:
>
> http://wikis.sun.com/display/OpenSolarisInfo/comstar+Administration
>
> http://blogs.sun.com/observatory/entry/iscsi_san

I found this useful too:
http://www.cuddletech.com/blog/pivot/entry.php?id=968

Basically a google search for "comstar iscsi" returns lots of useful info.

-B

--
Brandon High : bh...@freaks.com
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Can we get some documentation on iSCSI sharing after comstar took over?

[Scott Meilicke]

This is what I used:
http://wikis.sun.com/display/OpenSolarisInfo200906/How+to+Configure+iSCSI+Target+Ports

I distilled that to:

disable the old, enable the new (comstar)

* sudo svcadm disable iscsitgt
* sudo svcadm enable stmf

Then four steps (using my zfs/zpool info - substitute for yours):

* sudo zfs create -s -V 5t data01/san/gallardo/g (the -s makes it thin, -V 
specifies a block volume)
* sbdadm create-lu /dev/zvol/rdsk/data01/san/gallardo/g
* sudo itadm create-target
* sudo stmfadm add-view 600144F0E24785004A80910A0001

This should allow any initiator to connect to your volume, no security.

Not quite a one liner. After you create the target once (step 3), you do not 
have to do that again for the next volume. So three lines.

-Scott
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Can we get some documentation on iSCSI sharing after comstar took over?

[Cindy Swearingen]

Hi Svein,

Here's a couple of pointers:

http://wikis.sun.com/display/OpenSolarisInfo/comstar+Administration

http://blogs.sun.com/observatory/entry/iscsi_san

Thanks,

Cindy

On 03/16/10 12:15, Svein Skogen wrote:
Things used to be simple. 


"zfs create -V xxg -o shareiscsi=on pool/iSCSI/mynewvolume"

It worked.

Now we've got a new, feature-rich baby in town, called comstar, and so far all 
attempts at groking the excuse of a manpage has simply left me with a nasty 
headache.

_WHERE_ is the replacement one-line command that let me create a new 
iscsi-shared volume (I could then mount on my VMWare ESXi box)?

//Svein

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] Can we get some documentation on iSCSI sharing after comstar took over?

[Svein Skogen]

Things used to be simple. 

"zfs create -V xxg -o shareiscsi=on pool/iSCSI/mynewvolume"

It worked.

Now we've got a new, feature-rich baby in town, called comstar, and so far all 
attempts at groking the excuse of a manpage has simply left me with a nasty 
headache.

_WHERE_ is the replacement one-line command that let me create a new 
iscsi-shared volume (I could then mount on my VMWare ESXi box)?

//Svein
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] How to manage scrub priority or defer scrub?

[Khyron]

The issue as presented by Tonmaus was that a scrub was negatively impacting
his RAIDZ2 CIFS performance, but he didn't see the same impact with RAIDZ.
I'm not going to say whether that is a "problem" one way or the other; it
may
be expected behavior under the circumstances.  That's for ZFS developers to
speak on.  (This was one of many issues Tonmaus mentioned.)

However, what was lost was the context.  Tonmaus reported this behavior on
a commodity server using slow disks in an 11 disk RAIDZ2 set.  However, he
*really* wants to know if this will be an issue on a 100+ TB pool.  So his
examples were given on a pool that was possibly 5% of the size the pool that

he actually wants to deploy.  He never said any of this in the original
e-mail, so
Richard assumed the context to be the smaller system.  That's why I pointed
out all of the discrepancies and questions he could/should have asked which
might have yielded more useful answers.

There's quite a difference between the 11 disk RAIDZ2 set and a 100+ TB ZFS
pool, especially when the use case, VDEV layout and other design aspects of
the 100+ TB pool have not been described.

On Tue, Mar 16, 2010 at 13:41, David Dyer-Bennet  wrote:

>
> On Tue, March 16, 2010 11:53, thomas wrote:
> > Even if it might not be the best technical solution, I think what a lot
> of
> > people are looking for when this comes up is a knob they can use to say
> "I
> > only want X IOPS per vdev" (in addition to low prioritization) to be used
> > while scrubbing. Doing so probably helps them feel more at ease that they
> > have some excess capacity on cpu and vdev if production traffic should
> > come along.
> >
> > That's probably a false sense of moderating resource usage when the
> > current "full speed, but lowest prioritization" is just as good and would
> > finish quicker.. but, it gives them peace of mind?
>
> I may have been reading too quickly, but I have the impression that at
> least some of the people not happy with the current prioritization were
> reporting severe impacts to non-scrub performance when a scrub was in
> progress.  If that's the case, then they have a real problem, they're not
> just looking for more peace of mind in a hypothetical situation.
> --
> David Dyer-Bennet, d...@dd-b.net; http://dd-b.net/
> Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
> Photos: http://dd-b.net/photography/gallery/
> Dragaera: http://dragaera.info
>
> ___
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>



-- 
"You can choose your friends, you can choose the deals." - Equity Private

"If Linux is faster, it's a Solaris bug." - Phil Harman

Blog - http://whatderass.blogspot.com/
Twitter - @khyron4eva
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] How to manage scrub priority or defer scrub?

[David Dyer-Bennet]

On Tue, March 16, 2010 11:53, thomas wrote:
> Even if it might not be the best technical solution, I think what a lot of
> people are looking for when this comes up is a knob they can use to say "I
> only want X IOPS per vdev" (in addition to low prioritization) to be used
> while scrubbing. Doing so probably helps them feel more at ease that they
> have some excess capacity on cpu and vdev if production traffic should
> come along.
>
> That's probably a false sense of moderating resource usage when the
> current "full speed, but lowest prioritization" is just as good and would
> finish quicker.. but, it gives them peace of mind?

I may have been reading too quickly, but I have the impression that at
least some of the people not happy with the current prioritization were
reporting severe impacts to non-scrub performance when a scrub was in
progress.  If that's the case, then they have a real problem, they're not
just looking for more peace of mind in a hypothetical situation.
-- 
David Dyer-Bennet, d...@dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Posible newbie question about space between zpool and zfs file systems

[Stefan Walk]

On 15 Mar 2010, at 23:03, Tonmaus wrote:


Hi Cindy,
trying to reproduce this


For a RAIDZ pool, the zpool list command identifies
the "inflated" space
for the storage pool, which is the physical available
space without an
accounting for redundancy overhead.

The zfs list command identifies how much actual pool
space is available
to the file systems.


I am lacking 1 TB on my pool:

u...@filemeister:~$ zpool list daten
NAMESIZE  ALLOC   FREECAP  DEDUP  HEALTH  ALTROOT
daten10T  3,71T  6,29T37%  1.00x  ONLINE  -
u...@filemeister:~$ zpool status daten
 pool: daten
state: ONLINE
scrub: none requested
config:

   NAME  STATE READ WRITE CKSUM
   daten ONLINE   0 0 0
 raidz2-0ONLINE   0 0 0
   c10t2d0   ONLINE   0 0 0
   c10t3d0   ONLINE   0 0 0
   c10t4d0   ONLINE   0 0 0
   c10t5d0   ONLINE   0 0 0
   c10t6d0   ONLINE   0 0 0
   c10t7d0   ONLINE   0 0 0
   c10t8d0   ONLINE   0 0 0
   c10t9d0   ONLINE   0 0 0
   c11t18d0  ONLINE   0 0 0
   c11t19d0  ONLINE   0 0 0
   c11t20d0  ONLINE   0 0 0
   spares
 c11t21d0AVAIL

errors: No known data errors
u...@filemeister:~$ zfs list daten
NAMEUSED  AVAIL  REFER  MOUNTPOINT
daten  3,01T  4,98T   110M  /daten

I am counting 11 disks 1 TB each in a raidz2 pool. This is 11 TB  
gross capacity, and 9 TB net. Zpool is however stating 10 TB and zfs  
is stating 8TB. The difference between net and gross is correct, but  
where is the capacity from the 11th disk going?


Regards,

Tonmaus


This is because 1TB is not 1TB. The 1TB on your disk label means 10^12  
bytes, while 1TB in the OS means (2^10)^4 = 1024^4 bytes.

11*(1000**4)/(1024.0**4)
=> 10.0044417195022
So your 11 "disk label" TB are 10 "OS" TB. Fun, isn't it?

Best regards,
Stefan
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] [pkg-discuss] CR 6880994 and pkg fix

[Danek Duvall]

Frank Middleton wrote:

> But "pkg fix" flags an error in it's own inscrutable way. CCing
> pkg-discuss in case a pkg guru can shed any light on what the output of
> "pkg fix" (below) means. Presumably libc is OK, or it wouldn't boot :-).

The "problem" with libc here is that while /lib/libc.so.1 is delivered as
one set of contents, /usr/lib/libc/libc_hwcap*.so.1 is mounted on top.
Until bug 7926 is fixed, "pkg verify" doesn't look underneath the
mountpoint and so thinks that libc has the wrong bits.

Danek
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] How to manage scrub priority or defer scrub?

[thomas]

Even if it might not be the best technical solution, I think what a lot of 
people are looking for when this comes up is a knob they can use to say "I only 
want X IOPS per vdev" (in addition to low prioritization) to be used while 
scrubbing. Doing so probably helps them feel more at ease that they have some 
excess capacity on cpu and vdev if production traffic should come along.

That's probably a false sense of moderating resource usage when the current 
"full speed, but lowest prioritization" is just as good and would finish 
quicker.. but, it gives them peace of mind?
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] How to manage scrub priority or defer scrub?

[Bob Friesenhahn]

On Tue, 16 Mar 2010, Tonmaus wrote:


This wasn't mirror vs. raidz but raidz1 vs. raidz2, whereas the 
latter maxes out CPU and the former maxes out physical disc I/O. 
Concurrent payload degradation isn't that extreme on raidz1 pools, 
as it seems. Hence, the CPU theory that you still seem to be 
reluctant to follow.


If CPU is maxed out then that usually indicates some severe problem 
with choice of hardware or a misbehaving device driver.  Modern 
systems have an abundance of CPU.


I don't think that the size of the pool is particularly significant 
since zfs scrubs in a particular order and scrub throughput is dicated 
by access times and bandwidth.  In fact there should be less impact 
from scrub in a larger pool (even though scrub may take much longer) 
since the larger pool will have more vdevs.  The vdev design is most 
important.  Too many drives per vdev leads to poor performance, 
particularly if the drives are huge sluggish ones.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] dedup rollback taking a long time.

[John]

I probably lied about snv_134 above. I am probably running snv_133 as I don't 
think 134 had come out when I started this.
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] How to manage scrub priority or defer scrub?

[Bruno Sousa]

Well...i can only say "well said".

BTW i have a raidz2 with 9 vdevs with 4 disks each (sata enterprise
disks) and the scrub of the pool takes between 12 to 39 hours..depends
on the workload of the server.
So far it's acceptable but each case is a case i think...


Bruno

On 16-3-2010 14:04, Khyron wrote:
> In following this discussion, I get the feeling that you and Richard
> are somewhat
> talking past each other.  He asked you about the hardware you are
> currently running
> on, whereas you seem to be interested in a model for the impact of
> scrubbing on
> I/O throughput that you can apply to some not-yet-acquired hardware. 
>
> It should be clear by now that the model you are looking for does not
> exist given
> how new ZFS is, and Richard has been focusing his comments on your
> existing (home)
> configuration since that is what you provided specs for.
>
> Since you haven't provided specs for this larger system you may be
> purchasing in the
> future, I don't think anyone can give you specific guidance on what
> the I/O impact of
> scrubs on your configuration will be.  Richard seems to be giving more
> design guidelines
> and hints, and just generally good to know information to keep in mind
> while designing
> your solution.  Of course, he's been giving it in the context of your
> 11 disk wide
> RAIDZ2 and not the 200 TB monster you only described in the last e-mail.
>
> Stepping back, it may be worthwhile to examine the advice Richard has
> given, in the
> context of the larger configuration. 
>
> First, you won't be using commodity hardware for your enterprise-class
> storage system,
> will you?
>
> Second, I would imagine that as a matter of practice, most people
> schedule their pools
> to scrub as far away from prime hours as possible.  Maybe it's
> possible, and maybe it's
> not.  The question to the larger community should be "who is running a
> 100+ TB pool
> and how have you configured your scrubs?"  Or even "for those running
> 100+ TB pools,
> do your scrubs interfere with your production traffic/throughput?  If
> so, how do you
> compensate for this?"
>
> Third, as for ZFS scrub prioritization, Richard answered your question
> about that.  He
> said it is low priority and can be tuned lower.  However, he was
> answering within the
> context of an 11 disk RAIDZ2 with slow disks  His exact words were:
>
> "This could be tuned lower, but your storage is slow and *any* I/O
> activity will be
> noticed."
>
> If you had asked about a 200 TB enterprise-class pool, he may have had
> a different
> response.  I don't know if ZFS will make different decisisons
> regarding I/O priority on
> commodity hardware as opposed to enterprise hardware, but I imagine it
> does *not*. 
> If I'm mistaken, someone should correct me.  Richard also said "In
> b133, the priority
> scheduler will work better than on older releases."  That may not be
> an issue since
> you haven't acquired your hardware YET, but again, Richard didn't know
> that you
> were talking about a 200 TB behemoth because you never said that.
>
> Fourth, Richard mentioned a wide RAIDZ2 set.  Hopefully, if nothing
> else, we've
> seen that designing larger ZFS storage systems with pools composed of
> smaller top
> level VDEVs works better, and preferably mirrored top level VDEVs in
> the case of lots
> of small, random reads.  You didn't indicate the profile of the data
> to be stored on
> your system, so no one can realistically speak to that.  I think the
> general guidance
> is sound.  Multiple top level VDEVs, preferably mirrors.  If you're
> creating RAIDZ2
> top level VDEVs, then they should be smaller (narrower) in terms of
> the number of
> disks in the set.  11 would be too many, based on what I have seen and
> heard on
> this list cross referenced with the (little) information you have
> provided.
>
> RAIDZ2 would appear to require more CPU power that RAIDZ, based on the
> report
> you gave and thus may have less negative impact on the performance of
> your storage
> system.  I'll cop to that.  However, you never mentioned how your 200
> TB behemoth
> system will be used, besides an off-hand remark about CIFS.  Will it
> be serving CIFS?
> NFS?  Raw ZVOLs over iSCSI?  You never mentioned any of that.  Asking
> about CIFS
> if you're not going to serve CIFS doesn't make much sense.  That would
> appear to
> be another question for the ZFS gurus here -- WHY does RAIDZ2 cause so
> much
> negative performance impact on your CIFS service while RAIDZ does
> not?  Your
> experience is that a scrub of a RAIDZ2 maxed CPU while a RAIDZ scrub
> did not, right?
>
> Fifth, the pool scrub should probably be as far away from peak usage
> times as possible.
> That may or may not be feasible, but I don't think anyone would
> disagree with that
> advice.  Again, I know there are people running large pools who
> perform scrubs.  It
> might be worthwhile to directly ask what these people have experienced
> in terms of
> scrub performance on RAIDZ vs. RA

[zfs-discuss] dedup rollback taking a long time.

[John]

We currently have a opensolaris box running as a backup server, and to increase 
the redundancy I have started coping this to another server with 4 x 2TB in 
raidz and dedup. This was going fine taking about 10 hours to zfs send and 
receive each 70GB snaphot (no ZIL or cache setup), but on the last snapshot of 
the second file system the copy didn't complete (probably user error, I may 
have interrupted it). I had about 1.26TB of the 7.25 TB pool used and a dedup 
of about 2.60x. No problem I thought I will just rollback the snapshot and try 
again. That was now 6 days ago (I did reboot after 2 days, due to no ping 
response). Anyone like to hazard a guess to when this will finish?

I am running 134, is this issue/bug important enough to be fixed in a near 
future, or do I need to buy a bigger server and no use dedup? My main backup 
server is currently using 8TB of its 15.5TB but not using dedup.
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] How to manage scrub priority or defer scrub?

[Khyron]

In following this discussion, I get the feeling that you and Richard are
somewhat
talking past each other.  He asked you about the hardware you are currently
running
on, whereas you seem to be interested in a model for the impact of scrubbing
on
I/O throughput that you can apply to some not-yet-acquired hardware.

It should be clear by now that the model you are looking for does not exist
given
how new ZFS is, and Richard has been focusing his comments on your existing
(home)
configuration since that is what you provided specs for.

Since you haven't provided specs for this larger system you may be
purchasing in the
future, I don't think anyone can give you specific guidance on what the I/O
impact of
scrubs on your configuration will be.  Richard seems to be giving more
design guidelines
and hints, and just generally good to know information to keep in mind while
designing
your solution.  Of course, he's been giving it in the context of your 11
disk wide
RAIDZ2 and not the 200 TB monster you only described in the last e-mail.

Stepping back, it may be worthwhile to examine the advice Richard has given,
in the
context of the larger configuration.

First, you won't be using commodity hardware for your enterprise-class
storage system,
will you?

Second, I would imagine that as a matter of practice, most people schedule
their pools
to scrub as far away from prime hours as possible.  Maybe it's possible, and
maybe it's
not.  The question to the larger community should be "who is running a 100+
TB pool
and how have you configured your scrubs?"  Or even "for those running 100+
TB pools,
do your scrubs interfere with your production traffic/throughput?  If so,
how do you
compensate for this?"

Third, as for ZFS scrub prioritization, Richard answered your question about
that.  He
said it is low priority and can be tuned lower.  However, he was answering
within the
context of an 11 disk RAIDZ2 with slow disks  His exact words were:

"This could be tuned lower, but your storage is slow and *any* I/O activity
will be
noticed."

If you had asked about a 200 TB enterprise-class pool, he may have had a
different
response.  I don't know if ZFS will make different decisisons regarding I/O
priority on
commodity hardware as opposed to enterprise hardware, but I imagine it does
*not*.
If I'm mistaken, someone should correct me.  Richard also said "In b133, the
priority
scheduler will work better than on older releases."  That may not be an
issue since
you haven't acquired your hardware YET, but again, Richard didn't know that
you
were talking about a 200 TB behemoth because you never said that.

Fourth, Richard mentioned a wide RAIDZ2 set.  Hopefully, if nothing else,
we've
seen that designing larger ZFS storage systems with pools composed of
smaller top
level VDEVs works better, and preferably mirrored top level VDEVs in the
case of lots
of small, random reads.  You didn't indicate the profile of the data to be
stored on
your system, so no one can realistically speak to that.  I think the general
guidance
is sound.  Multiple top level VDEVs, preferably mirrors.  If you're creating
RAIDZ2
top level VDEVs, then they should be smaller (narrower) in terms of the
number of
disks in the set.  11 would be too many, based on what I have seen and heard
on
this list cross referenced with the (little) information you have provided.

RAIDZ2 would appear to require more CPU power that RAIDZ, based on the
report
you gave and thus may have less negative impact on the performance of your
storage
system.  I'll cop to that.  However, you never mentioned how your 200 TB
behemoth
system will be used, besides an off-hand remark about CIFS.  Will it be
serving CIFS?
NFS?  Raw ZVOLs over iSCSI?  You never mentioned any of that.  Asking about
CIFS
if you're not going to serve CIFS doesn't make much sense.  That would
appear to
be another question for the ZFS gurus here -- WHY does RAIDZ2 cause so much
negative performance impact on your CIFS service while RAIDZ does not?  Your

experience is that a scrub of a RAIDZ2 maxed CPU while a RAIDZ scrub did
not, right?

Fifth, the pool scrub should probably be as far away from peak usage times
as possible.
That may or may not be feasible, but I don't think anyone would disagree
with that
advice.  Again, I know there are people running large pools who perform
scrubs.  It
might be worthwhile to directly ask what these people have experienced in
terms of
scrub performance on RAIDZ vs. RAIDZ2, or in general.

Finally, I would also note that Richard has been very responsive to your
questions (in
his own way) but you increasingly seem to be hostile and even disrespectful
toward
him.  (I've noticed this in more then one of your e-mails; they sound
progressively
more self-centered and selfish.  That's just my opinion.)  If this is a
community, that's
not a helpful way to treat a senior member of the community, even if he's
not
answering the question you want answered.

Keep in mind that asking the wrong questions 

[zfs-discuss] dedupratio riddle

[Paul van der Zwan]

On Opensolaris build 134, upgraded from older versions, I have an rpool for 
which I had switch on dedup for a few weeks. 
After that I switched to back on.
Now it seems the dedup ratio is stuck at a value of 1.68.
Even when I copy more then 90 GB of data it still remains at 1.68.
Any ideas ?

Paul
Here is some evidence…

Before the copy :
$ zpool list
NAMESIZE  ALLOC   FREECAP  DEDUP  HEALTH  ALTROOT
rpool   931G   132G   799G14%  1.68x  ONLINE  -
$ 

After the copy :
$ zpool list
NAMESIZE  ALLOC   FREECAP  DEDUP  HEALTH  ALTROOT
rpool   931G   225G   706G24%  1.68x  ONLINE  -
$
It has only been enabled for 11 days last month.

$ pfexec zpool history |grep dedup
2010-02-11.21:19:42 zfs set dedup=verify rpool
2010-02-22.21:38:15 zfs set dedup=off rpool

And it is off on all filesystems:
$ zfs get -r dedup rpool
NAME  PROPERTY  VALUE  
SOURCE
rpool dedup off
local
rp...@20100227dedup -  -
rpool/ROOTdedup off
inherited from rpool
rpool/r...@20100227   dedup -  -
rpool/ROOT/b131-zones dedup off
inherited from rpool
rpool/ROOT/b131-zo...@20100227dedup -  -
rpool/ROOT/b132   dedup off
inherited from rpool
rpool/ROOT/b...@20100227  dedup -  -
rpool/ROOT/b133   dedup off
inherited from rpool
rpool/ROOT/b134   dedup off
inherited from rpool
rpool/ROOT/b...@install   dedup -  -
rpool/ROOT/b...@2010-02-07-11:19:05   dedup -  -
rpool/ROOT/b...@2010-02-20-15:59:22   dedup -  -
rpool/ROOT/b...@20100227  dedup -  -
rpool/ROOT/b...@2010-03-11-19:18:51   dedup -  -
rpool/dumpdedup off
inherited from rpool
rpool/d...@20100227   dedup -  -
rpool/export  dedup off
inherited from rpool
rpool/exp...@20100227 dedup -  -
rpool/export/home dedup off
inherited from rpool
rpool/export/h...@20100227dedup -  -
rpool/export/home/beheer  dedup off
inherited from rpool
rpool/export/home/beh...@20100227 dedup -  -
rpool/export/home/paulz   dedup off
inherited from rpool
rpool/export/home/pa...@20100227  dedup -  -
rpool/export/sharededup off
inherited from rpool
rpool/export/sh...@20100227   dedup -  -
rpool/local   dedup off
inherited from rpool
rpool/lo...@20100227  dedup -  -
rpool/paulzmail   dedup off
inherited from rpool
rpool/paulzm...@20100227  dedup -  -
rpool/pkg dedup off
inherited from rpool
rpool/p...@20100227dedup -  
-
rpool/swapdedup off
inherited from rpool
rpool/s...@20100227   dedup -  -
rpool/zones   dedup off
inherited from rpool
rpool/zo...@20100227  dedup -  -
rpool/zones/buildzone dedup off
inherited from rpool
rpool/zones/buildz...@20100227dedup -  -
rpool/zones/buildzone/ROOTdedup off
inherited from rpool
rpool/zones/buildzone/r...@20100227   dedup -  -
rpool/zones/buildzone/ROOT/zbe-1  dedup off
inherited from rpool
rpool/zones/buildzone/ROOT/zb...@20100227 dedup -  -
rpool/zones/buildzone/ROOT/zbe-2  dedup off
inherited from rpool
rpool/zones/buildzone/ROOT/zb...@20100227 dedup -  -
rpool

[zfs-discuss] Usage of hot spares and hardware allocation capabilities.

[Robin Axelsson]

I've been informed that newer versions of ZFS supports the usage of hot spares 
which is denoted for drives that are not in use but available for 
resynchronization/resilvering should one of the original drives fail in the 
assigned storage pool.

I'm a little sceptical about this because even the hot spare will be running 
for the same duration as the other disks in the pool and therefore will be 
exposed to the same levels of hardware degradation and failures unless it is 
put to sleep during the time it is not being used for storage. So, is there a 
sleep/hibernation/standby mode that the hot spares operate in or are they on 
all the time regardless of whether they are in use or not?

Usually the hot spare is on a not so well-performing SAS/SATA controller, so 
given the scenario of a hard drive failure upon which a hot spare has been used 
for resilvering of say a raidz2 cluster, can I move the resilvered hot spare to 
the faster controller by letting it take the faulty hard drive's space using 
the "zpool offline", "zpool online" commands?

To be more general; are the hard drives in the pool "hard coded" to their 
SAS/SATA channels or can I swap their connections arbitrarily if I would want 
to do that? Will zfs automatically identify the association of each drive of a 
given pool or tank and automatically reallocate them to put the 
pool/tank/filesystem back in place?
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] How to manage scrub priority or defer scrub?

[Tonmaus]

Hi Richard,

> > - scrubbing the same pool, configured as raidz1
> didn't max out CPU which is no surprise (haha, slow
> storage...) the notable part is that it didn't slow
> down payload that much either.
> 
> raidz creates more, smaller writes than a mirror or
> simple stripe. If the disks are slow,
> then the IOPS will be lower and the scrub takes
> longer, but the I/O scheduler can
> manage the queue better (disks are slower).

This wasn't mirror vs. raidz but raidz1 vs. raidz2, whereas the latter maxes 
out CPU and the former maxes out physical disc I/O. Concurrent payload 
degradation isn't that extreme on raidz1 pools, as it seems. Hence, the CPU 
theory that you still seem to be reluctant to follow.


> There are several
> bugs/RFEs along these lines, something like:
> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bu
> g_id=6743992

Thanks to pointing at this. As it seems, it's a problem for a couple of years 
already. Obviously, the opinion is being shared that this a management problem, 
not a HW issue.

As a Project Manager I will soon have to take a purchase decision for an 
archival storage system (A/V media), and one of the options we are looking into 
is SAMFS/QFS solution including tiers on disk with ZFS. I will have to make up 
my mind if the pool sizes we are looking into (typically we will need 150-200 
TB) are really manageable under the current circumstances when we think about 
including zfs scrub in the picture. From what I have learned here it rather 
looks as if there will be an extra challenge, if not even a problem for the 
system integrator. That's unfortunate.

Regards,

Tonmaus
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] can I configure a fc-san initiator for a storage array?

[likaijun]

I have a machine with opensolaris snv111b .I want to let it use to a fc-san 
initiator NAS header in my total system.
Now I configure FC HBA port from qlt to qlc mode as initiator wich command 
update_drv . 
I can use stmfadm list-target -v to find the  FC-SAN target  is conneted
Target: wwn.211B328A3224
Operational Status: Online
Provider Name : qlt
Alias : qlt2,0
Protocol  : Fibre Channel
Sessions  : 1
   [i] Initiator: wwn.211B328AF72C[/i]
Alias: -
Logged in since: Tue Mar 16 11:49:01 2010

How can I configure a fcsan initiator nor a iscsi initiator? can you give me 
some suggestion?
thanks.
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS - VMware ESX --> vSphere Upgrade : Zpool Faulted

[Andrew]

Hi again,

Out of interest, could this problem have been avoided if the ZFS configuration 
didnt rely on a single disk? i.e. RAIDZ etc 

Thanks
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss