Re: [zfs-discuss] ZFS flash issue

[Ketan]

Thanks Cindy & Enda for the info ..
-- 
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 proerty aclmode gone in 147?

[Paul B. Henson]

On 9/28/2010 2:13 PM, Nicolas Williams wrote:

>> Or aclmode=deny, which is pretty simple, not very confusing, and 
basically

>> the only paradigm that will prevent chmod from breaking your ACL.
>
> That can potentially render many applications unusable.

Yes. Which is why it obviously wouldn't be the default, and probably 
highly inadvisable for a root pool. But for a data file system whose 
usage model demands pure ACLs, which you want to make sure are never 
discarded, why shouldn't it be available?


> Suppose you make chmod(1) not use chomd(2)

Now you're just being pedantic ;).

> But then what about scripts that use chmod(1)?

The user/administrator who intentionally elected to implement the 
nondefault option clearly cares more about not losing their ACLs than 
about some random scripts failing. It seems the vast majority of 
arguments against implementing this option have been of the form "bad 
thing  might happen, and the user would be ". 
It's my foot, I don't appreciate people trying to prevent me from 
shooting it, particularly if there happens to be some poisonous animal 
sitting on it that is the actual target :).


The version of samba bundled with Solaris 10 seems to insist on 
chmod'ing stuff. I've tried all of the various options that should 
disable mapping to mode bits, yet still randomly when people copy files 
in over CIFS, ACL's get destroyed by chmod interaction and access 
control is broken. I finally ended up having to preload a shared object 
that overrides chmod and turns it into a nullop. This would have been 
the perfect scenario for aclmode=ignore, I don't care what samba may or 
may not want to do, if the file has an ACL I don't want it mucked with. 
So why exactly shouldn't I have that functionality available for this 
scenario?


> Seems like a lot of work for little gain, and high
> support call generation rate.

Yup. I agree that any attempt to impose sanity on the application of 
chmod onto an object with an ACL by somehow combining the existing ACL 
with the new mode is pointless. It seems that there are three reasonable 
options when attempting to update the permissions of an object with an 
ACL via the legacy chmod call -- just discard the ACL, deny the 
attempted change, or ignore it.


>> Yep. And a good first step towards an ACL world would be providing a 
way to

>> keep chmod from destroying ACLs in the current world...
>
> I don't think that will happen...

Not in the official Oracle version of Solaris, but given Oracle's 
choices it seems that's not going to be the only version of the 
OpenSolaris code base floating around. Maybe the Illumos community will 
be a little more open to providing users with functionality that could 
be extremely valuable in some scenarios and doesn't hurt anybody who 
doesn't intentionally choose to use it... I said before I'd be willing 
to implement it myself if there was some reasonable likelihood it would 
be accepted, once the whole Illumos thing settles down I think I'll make 
that offer again and see what happens.



--
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] drive speeds etc

[Simon Breden]

> described problems with WD aren't okay for
>  non-critical
> evelopment/backup/home use either.

Indeed. I don't use WD drives for RAID any longer.

>  The statement
> from WD is nothing
> but an attempt to upsell you, to differentiate the
> market so they can
> tap into the demand curve at multiple points

Yes, I'm quite aware of this.


> Don't let this
> stuff get a foothold inside your brain.

Ok, thanks, I'll try to ensure that never happens :P

> ``mixing'' drives within a stripe is a good idea
> because it protects
> you from bad batches and bad models/firmwares, which
> are not rare in
> recent experience!

Yep, that's one way, although you also multiply the risk of at least one type 
of drive being a lemon.

Another is to research good drives & firmwares and stick with those. Twice out 
of two drive choosing/buying occasions, this latter choice has served me well. 
Zero read/write/checksum errors so far in almost 3 years. I must be lucky, very 
lucky :)

>  I always mix drives and included
> WD in that mix up
> until this latest rash of problems.

I avoided WD (for RAID) as soon as these problems showed up and bought another 
manufacturer's drives.

I still buy their Caviar Black drives as scratch video editing drives though, 
as they're pretty good.
-- 
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 proerty aclmode gone in 147?

[Nicolas Williams]

On Wed, Sep 29, 2010 at 10:15:32AM +1300, Ian Collins wrote:
> Based on my own research, experimentation and client requests, I
> agree with all of the above.

Good to know.

> I have be re-ordering and cleaning (deny) ACEs for one client for a
> couple of years now and we haven't seen any user complaints.  In
> their environment, all ACLs started life as POSIX (from a Solaris 9
> host) and with the benefit of hindsight, I would have cleaned them
> up on import to ZFS rather than simply reading the POSIX ACL and
> writing back to ZFS.

The saddest scenario would be when you have to interop with NFSv3
clients whose users (or their apps) are POSIX ACL happy, but whose files
also need to be accessible from NFSv4, SMB, and local ZPL clients where
the users (possibly the same users, or their apps) are also ZFS ACL
happy.  Particularly if you also have Windows clients and the users edit
file ACLs there too!  Thankfully this is relatively easy to avoid
because: apps that edit ACLs are few and far between, thus easy to
remediate, and users should not really be manually setting POSIX Draft
and ZFS/NFSv4/SMB ACLs on the same files.

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

Re: [zfs-discuss] zfs proerty aclmode gone in 147?

[Ian Collins]

On 09/29/10 09:38 AM, Nicolas Williams wrote:

I've researched this enough (mainly by reading most of the ~240 or so
relevant zfs-discuss posts and several bug reports) to conclude the
following:

  - ACLs derived from POSIX mode_t and/or POSIX Draft ACLs that result in
DENY ACEs are enormously confusing to users.

  - ACLs derived from POSIX mode_t and/or POSIX Draft ACLs that result in
DENY ACEs are susceptible to ACL re-ordering when modified from
Windows clients -which insist on DENY ACEs first-, leading to much
confusion.

  - This all gets more confusing when hand-crafted ZFS inherittable ACEs
are mixed with chmod(2)s with the old aclmode=groupmask setting.

The old aclmode=passthrough setting was dangerous and had to be removed,
period.  (Doing chmod(600) would not necessarily deny other users/groups
access -- that's very, very broken.)

That only leaves aclmode=discard and some variant of aclmode=groupmask
that is less confusing.

But here's the thing: the only time that groupmasking results in
sensible ACLs is when it doesn't require DENY ACEs, which in turn is
only when mode_t bits and/or POSIX ACLs are strictly non-increasing
(e.g., 777, 775, 771, 750, 755, 751, etcetera, would all be OK, but 757
would not be).

The problem then is this: if you have an aclmode setting that sometimes
groupmasks and sometimes discards... that'll be confusing too!

So one might wonder: can one determine user intent from the ACL prior to
the change and the mode/POSIX ACL being set, and then edit the ZFS ACL
in a way that approximates the user's intention?  I believe that would
be possible, but risky too, as the need to avoid DENY ACEs (see Windows
issue) would often result in more permissive ACLs than the user actually
intended.

Taken altogether I believe that aclmode=discard is the simplest setting
to explain and understand.  Perhaps eventually a variant of groupmasking
will be developed that is also simple to explain and understand, but
right now I very much doubt it (and yes, I've tried myself).  But much
better than that would be if we just move to a ZFS ACL world (which,
among other things, means we'll need a simple libc API for editing
ACLs).

Note, incidentally, that there's a groupmasking behavior left in ZFS at
this time: on create of objects in directories with inherittable ACEs
and with aclinherit=passthrough*.

   
Based on my own research, experimentation and client requests, I agree 
with all of the above.


I have be re-ordering and cleaning (deny) ACEs for one client for a 
couple of years now and we haven't seen any user complaints.  In their 
environment, all ACLs started life as POSIX (from a Solaris 9 host) and 
with the benefit of hindsight, I would have cleaned them up on import to 
ZFS rather than simply reading the POSIX ACL and writing back to ZFS.


--
Ian.

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

Re: [zfs-discuss] zfs proerty aclmode gone in 147?

[Nicolas Williams]

On Tue, Sep 28, 2010 at 02:03:30PM -0700, Paul B. Henson wrote:
> On Tue, 28 Sep 2010, Nicolas Williams wrote:
> 
> > I've researched this enough (mainly by reading most of the ~240 or so
> > relevant zfs-discuss posts and several bug reports)
> 
> And I think some fair fraction of those posts were from me, so I'll try not
> to start rehashing old discussions ;).

:)

> > That only leaves aclmode=discard and some variant of aclmode=groupmask
> > that is less confusing.
> 
> Or aclmode=deny, which is pretty simple, not very confusing, and basically
> the only paradigm that will prevent chmod from breaking your ACL.

That can potentially render many applications unusable.

> > So one might wonder: can one determine user intent from the ACL prior to
> > the change and the mode/POSIX ACL being set, and then edit the ZFS ACL
> > in a way that approximates the user's intention?
> 
> You're assuming the user is intentionally executing the chmod, or even
> *aware* of it happening. Probably at least 99% of the chmod calls executed
> on a file with a ZFS ACL at my site are the result of non-ACL aware legacy
> apps being stupid. In which case the *user* intent to to *leave the damn
> ACL alone* :)...

But that's not really clear.  The user is running some app.  The app
does some chmod(2)ing on behalf of the user.  The user may also use
chmod(1).  Now what?  Suppose you make chmod(1) not use chomd(2), so as
to be able to say that all chmod(2) calls are made by "apps", not the
user.   But then what about scripts that use chmod(1)?

Basically, I think intent can be estimated in some cases, and combined
with some simplifying assumptions (that will sometimes be wrong), such
as "security entities are all distinct, non-overlapping" (as a way to
minimize the number of DENY ACEs needed) can yield a groupmasking
algorithm that doesn't suck.  However, it'd still not be easy to
explain, and it'd still result in surprises (since the above assumption
will often be wrong, leading to more permissive ACLs than the user might
have intended!).  Seems like a lot of work for little gain, and high
support call generation rate.

> > But much better than that would be if we just move to a ZFS ACL world
> > (which, among other things, means we'll need a simple libc API for
> > editing ACLs).
> 
> Yep. And a good first step towards an ACL world would be providing a way to
> keep chmod from destroying ACLs in the current world...

I don't think that will happen...

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

Re: [zfs-discuss] Pools inside pools

[Markus Kovero]

> Yes. But what is enough reserved free memory? If you need 1Mb for a normal 
> configuration you might need 2Mb when you are doing ZFS on ZFS. (I am just 
> guessing).
> This is the same problem as mounting an NFS server on itself via NFS. Also 
> not supported.

> The system has shrinkable caches and so on, but that space will sometimes run 
> out. All of it. There is also swap to use, but if that is on ZFS

> These things are also very hard to test.

I was able to see opensolaris snv_134 to become unresponsive due lack of memory 
with nested pool configuration today. It took around 12hours issuing writes 
around 1,2-1,5GB/s with system that had 48GB of ram.
Anyway, setting zfs_arc_max in /etc/system seemed to do the trick, seems to 
behave like expected even under heavier load. Performance is actually pretty 
good.

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

Re: [zfs-discuss] zfs proerty aclmode gone in 147?

[Paul B. Henson]

On Tue, 28 Sep 2010, Nicolas Williams wrote:

> I've researched this enough (mainly by reading most of the ~240 or so
> relevant zfs-discuss posts and several bug reports)

And I think some fair fraction of those posts were from me, so I'll try not
to start rehashing old discussions ;).

> That only leaves aclmode=discard and some variant of aclmode=groupmask
> that is less confusing.

Or aclmode=deny, which is pretty simple, not very confusing, and basically
the only paradigm that will prevent chmod from breaking your ACL.

> So one might wonder: can one determine user intent from the ACL prior to
> the change and the mode/POSIX ACL being set, and then edit the ZFS ACL
> in a way that approximates the user's intention?

You're assuming the user is intentionally executing the chmod, or even
*aware* of it happening. Probably at least 99% of the chmod calls executed
on a file with a ZFS ACL at my site are the result of non-ACL aware legacy
apps being stupid. In which case the *user* intent to to *leave the damn
ACL alone* :)...

> But much better than that would be if we just move to a ZFS ACL world
> (which, among other things, means we'll need a simple libc API for
> editing ACLs).

Yep. And a good first step towards an ACL world would be providing a way to
keep chmod from destroying ACLs in the current world...


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs proerty aclmode gone in 147?

[Nicolas Williams]

On Tue, Sep 28, 2010 at 12:18:49PM -0700, Paul B. Henson wrote:
> On Sat, 25 Sep 2010, [iso-8859-1] Ralph Böhme wrote:
> 
> > Darwin ACL model is nice and slick, the new NFSv4 one in 147 is just
> > braindead. chmod resulting in ACLs being discarded is a bizarre design
> > decision.
> 
> Agreed. What's the point of ACLs that disappear? Sun didn't want to fix
> acl/chmod interaction, maybe one of the new OpenSolaris forks will do the
> right thing...

I've researched this enough (mainly by reading most of the ~240 or so
relevant zfs-discuss posts and several bug reports) to conclude the
following:

 - ACLs derived from POSIX mode_t and/or POSIX Draft ACLs that result in
   DENY ACEs are enormously confusing to users.

 - ACLs derived from POSIX mode_t and/or POSIX Draft ACLs that result in
   DENY ACEs are susceptible to ACL re-ordering when modified from
   Windows clients -which insist on DENY ACEs first-, leading to much
   confusion.

 - This all gets more confusing when hand-crafted ZFS inherittable ACEs
   are mixed with chmod(2)s with the old aclmode=groupmask setting.

The old aclmode=passthrough setting was dangerous and had to be removed,
period.  (Doing chmod(600) would not necessarily deny other users/groups
access -- that's very, very broken.)

That only leaves aclmode=discard and some variant of aclmode=groupmask
that is less confusing.

But here's the thing: the only time that groupmasking results in
sensible ACLs is when it doesn't require DENY ACEs, which in turn is
only when mode_t bits and/or POSIX ACLs are strictly non-increasing
(e.g., 777, 775, 771, 750, 755, 751, etcetera, would all be OK, but 757
would not be).

The problem then is this: if you have an aclmode setting that sometimes
groupmasks and sometimes discards... that'll be confusing too!

So one might wonder: can one determine user intent from the ACL prior to
the change and the mode/POSIX ACL being set, and then edit the ZFS ACL
in a way that approximates the user's intention?  I believe that would
be possible, but risky too, as the need to avoid DENY ACEs (see Windows
issue) would often result in more permissive ACLs than the user actually
intended.

Taken altogether I believe that aclmode=discard is the simplest setting
to explain and understand.  Perhaps eventually a variant of groupmasking
will be developed that is also simple to explain and understand, but
right now I very much doubt it (and yes, I've tried myself).  But much
better than that would be if we just move to a ZFS ACL world (which,
among other things, means we'll need a simple libc API for editing
ACLs).

Note, incidentally, that there's a groupmasking behavior left in ZFS at
this time: on create of objects in directories with inherittable ACEs
and with aclinherit=passthrough*.

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

Re: [zfs-discuss] zfs proerty aclmode gone in 147?

[Paul B. Henson]

On Sat, 25 Sep 2010, [iso-8859-1] Ralph Böhme wrote:

> Darwin ACL model is nice and slick, the new NFSv4 one in 147 is just
> braindead. chmod resulting in ACLs being discarded is a bizarre design
> decision.

Agreed. What's the point of ACLs that disappear? Sun didn't want to fix
acl/chmod interaction, maybe one of the new OpenSolaris forks will do the
right thing...


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] drive speeds etc

[Simon Breden]

IIRC the currently available WD Caviar Black models no longer enable TLER to be 
set. For WD drives, to have TLER capability you will need to buy their 
enterprise models like REx models which cost mucho $$$.
-- 
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 flash issue

[Enda O'Connor]

On 28/09/2010 10:20, Ketan wrote:

I have created a solaris9 zfs root flash archive for sun4v environment which i 
'm tryin to use for upgrading solaris10 u8 zfs root based server using live 
upgrade.

one cannot use zfs flash archive with luupgrade, that is with zfs root a 
flash archive archvies the entire root pool ( there is a -D to exclude 
datasets ), and can only be installed via jumpstart. There is no way to 
provision a BE using a flash archive yet, or at least not that I'm aware of.


Enda



following is my current system status


lustatus
Boot Environment   Is   Active ActiveCanCopy
Name   Complete NowOn Reboot Delete Status
--  -- - -- --
zfsBE  yes  yesyes   no -
zfsBEu9yes  no noyes-



when i try to upgrade the with luupgrade i get following error



luupgrade -f -n zfsBEu9 -s /mnt -a /flash/zfsBEu9.flar

63521 blocks
miniroot filesystem is
Mounting miniroot at
Validating the contents of the media.
The media is a standard Solaris media.
Validating the contents of the miniroot.
Locating the flash install program.
Checking for existence of previously scheduled Live Upgrade requests.
Constructing flash profile to use.
Creating flash profile for BE.
Performing the operating system flash install of the BE.
CAUTION: Interrupting this process may leave the boot environment unstable or 
unbootable.
ERROR: The flash install failed; pfinstall returned these diagnostics:

ERROR: Field 2 - Invalid disk name (zfsBEu9)
The Solaris flash install of the BE  failed.


What could be the reason for this .. is there anything i 'm not doin k ?


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

Re: [zfs-discuss] Data transfer taking a longer time than expected (Possibly dedup related)

[Tom]

Thanks a lot for that. I'm not experienced in reading the output of dtrace,
but I'm pretty sure that dedup was the cause here, as I disabling it during
the transfer, immediately raised the transfer speed to ~100MB/s.

Thanks for the article you linked to — it seems my system would need about
16GB RAM for dedup to work smoothly in my case...



On Fri, Sep 24, 2010 at 11:10 PM, David Blasingame Oracle <
david.blasing...@oracle.com> wrote:

>  How do you know it is dedup causing the problem?
>
> You can check to see how much is by looking at the threads (look for ddt)
>
> mdb -k
>
> ::threadlist -v
>
> or dtrace it.
>
> fbt:zfs:ddt*:entry
>
> You can disable dedup.  I believe current dedup data stays until it gets
> over written.  I'm not sure what send would do, but I would assume the new
> filesystem if dedup is not enabled would not have dedup'd data.
>
> You might also want to read.
>
> http://blogs.sun.com/roch/entry/dedup_performance_considerations1
>
> As far as the impact of  on a move operation, When I do a test to
> move a file from one file system to another an  the operation, the
> file is intact on the original filesystem and on the new filesystem it is
> partial.  So you would have to be careful about which data has already been
> copied.
>
> Dave
>
> On 09/24/10 14:34, Thomas S. wrote:
>
> Hi all
>
> I'm currently moving a fairly big dataset (~2TB) within the same zpool. Data 
> is being moved from a dataset to another, which has dedup enabled.
>
> The transfer started at quite a slow transfer speed — maybe 12MB/s. But it is 
> now crawling to a near halt. Only 800GB has been moved in 48 hours.
>
> I looked for similar problems on the forums and other places, and it seems 
> dedup needs a much bigger amount of RAM than the server currently has (3GB), 
> to perform smoothly for such an operation.
>
> My question is, how can I gracefully stop the ongoing operation? What I did 
> was simply "mv temp/* new/" in an ssh session (which is still open).
>
> Can I disable dedup on the dataset while the transfer is going on? Can I 
> simply Ctrl-C the procress to stop it? Shoul I be careful of anything?
>
> Help would be appreciated
>
>
>
>
> --
>
>
>
>
>
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Kernel panic on ZFS import - how do I recover?

[Meilicke, Scott]

Brilliant. I set those parameters via /etc/system, rebooted, and the pool
imported with just the ­f switch. I had seen this as an option earlier,
although not that thread, but was not sure it applied to my case.

Scrub is running now. Thank you very much!

-Scott


On 9/23/10 7:07 PM, "David Blasingame Oracle" 
wrote:

> Have you tried setting zfs_recover & aok in /etc/system or setting it with the
> mdb?
> 
> Read how to set via /etc/system
> http://opensolaris.org/jive/thread.jspa?threadID=114906
> 
> mdb debugger
> http://www.listware.net/201009/opensolaris-zfs/46706-re-zfs-discuss-how-to-set
> -zfszfsrecover1-and-aok1-in-grub-at-startup.html
> 
> After you get the variables set and system booted, try importing, then running
> a scrub. 
> 
> Dave
> 
> On 09/23/10 19:48, Scott Meilicke wrote:
>>  
>> I posted this on the www.nexentastor.org 
>> forums, but no answer so far, so I apologize if you are seeing this twice. I
>> am also engaged with nexenta support, but was hoping to get some additional
>> insights here. 
>> 
>> I am running nexenta 3.0.3 community edition, based on 134. The box crashed
>> yesterday, and goes into a reboot loop (kernel panic) when trying to import
>> my data pool, screenshot attached. What I have tried thus far:
>> 
>> Boot off of DVD, both 3.0.3 and 3.0.4 beta 8. 'zpool import -f data01' causes
>> the panic in both cases.
>> Boot off of 3.0.4 beta 8, ran zpool import -fF data01
>> That gives me a message like "Pool data01 returned to its stat as of ...",
>> and then panics.
>> 
>> The import -fF does seem to import the pool, but then immediately panic. So
>> after booting off of DVD, I can boot from my hard disks, and the system will
>> not import the pool because it was last imported from another system.
>> 
>> I have moved /etc/zfs/zfs.cache out of the way, but no luck after a reboot
>> and import.
>> 
>> zpool import shows all of my disks are OK, and the pool itself is online.
>> 
>> Is it time to start working with zdb? Any suggestions?
>> 
>> This box is hosting development VMs, so I have some people idling their
>> thumbs at the moment.
>> 
>> Thanks everyone,
>> 
>> -Scott
>>   
>>  
>> 
>> 
>> 
>> ___
>> zfs-discuss mailing list
>> zfs-discuss@opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>>   
> 



We value your opinion!  How may we serve you better? 
Please click the survey link to tell us how we are doing:
http://www.craneae.com/ContactUs/VoiceofCustomer.aspx
Your feedback is of the utmost importance to us. Thank you for your time.

Crane Aerospace & Electronics Confidentiality Statement:
The information contained in this email message may be privileged and is 
confidential information intended only for the use of the recipient, or any 
employee or agent responsible to deliver it to the intended recipient. Any 
unauthorized use, distribution or copying of this information is strictly 
prohibited 
and may be unlawful. If you have received this communication in error, please 
notify 
the sender immediately and destroy the original message and all attachments 
from 
your electronic files.

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

Re: [zfs-discuss] How to fsck the spacemap?

[Stephan Ferraro]

Am 19.09.2010 um 19:24 schrieb Victor Latushkin:

> 
> On Sep 19, 2010, at 9:06 PM, Stephan Ferraro wrote:
> 
>> Am 19.09.2010 um 18:59 schrieb Victor Latushkin:
>> 
>>> On Sep 19, 2010, at 12:08 AM, Stephan Ferraro wrote:
>>> 
 Is there a way to fsck the spacemap?
 Does scrub helps for this?
>>> 
>>> No, because issues that you see are internal inconsistencies with unclear 
>>> nature.
>>> 
>>> Though as actual issue varies from one inctance to another this is likely 
>>> some random corruption.
>> 
>> 
>> The error repeated in endless loop because the server rebooted in endless 
>> loop and each time when it booted up ZFS it showed this ASSERTION error of 
>> the corrupt spacemap every time in the same memory location.
> 
> Once it is there you'll trip various assertions each time affected space map 
> is loaded. By random corruption I mean that it is different each time you 
> encounter it another time after fixing it.


I admit that hardware is probably the most cheapest you can get. I rent a 
server at Hetzner hosting service which provide a rescue system of OpenSolaris 
snv_111b.

-- 
Best regards,
Stephan FERRARO
Director & Member - Ferraro Ltd. - IT Linux & UNIX solutions

Rechtliche Informationen:
-
Name der Gesellschaft:  FERRARO Ltd.
Gesellschafter und Geschäftsführer: Stephan Ferraro
Registergericht:Amtsgericht 
Stuttgart
Registernummer: HRB 724764
Umsatzsteuer-Indentifikationsnummer:DE814799566

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

Re: [zfs-discuss] How to fsck the spacemap?

[Stephan Ferraro]

Am 19.09.2010 um 18:59 schrieb Victor Latushkin:

> On Sep 19, 2010, at 12:08 AM, Stephan Ferraro wrote:
> 
>> Is there a way to fsck the spacemap?
>> Does scrub helps for this?
> 
> No, because issues that you see are internal inconsistencies with unclear 
> nature.
> 
> Though as actual issue varies from one inctance to another this is likely 
> some random corruption.


The error repeated in endless loop because the server rebooted in endless loop 
and each time when it booted up ZFS it showed this ASSERTION error of the 
corrupt spacemap every time in the same memory location.

-- 
Best regards,
Stephan FERRARO
Director & Member - Ferraro Ltd. - IT Linux & UNIX solutions

Rechtliche Informationen:
-
Name der Gesellschaft:  FERRARO Ltd.
Gesellschafter und Geschäftsführer: Stephan Ferraro
Registergericht:Amtsgericht 
Stuttgart
Registernummer: HRB 724764
Umsatzsteuer-Indentifikationsnummer:DE814799566

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

Re: [zfs-discuss] Mac OS X clients with ZFS server

[Erik Ableson]

The only tweak needed was making sure that I used the FQDN of the client 
machines (with appropriate reverse lookups in my DNS) for the sharenfs 
properties. 

Envoyé de mon iPhone

Le 16 sept. 2010 à 17:15, Rich Teer  a écrit :

> On Thu, 16 Sep 2010, Erik Ableson wrote:
> 
>> OpenSolaris snv129
> 
> Hmm, SXCE snv_130 here.  Did you have to do any server-side tuning
> (e.g., allowing remote connections), or did it just work out of the
> box?  I know that Sendmail needs some gentle persuasion to accept
> remote connections out of the box; perhaps lockd is the same?
> 
> -- 
> Rich Teer, Publisher
> Vinylphile Magazine
> 
> www.vinylphilemag.com
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Mac OS X clients with ZFS server

[Erik Ableson]

Le 16 sept. 2010 à 16:18, Rich Teer  a écrit :

> On Thu, 16 Sep 2010, erik.ableson wrote:
> 
>> And for reference, I have a number of 10.6 clients using NFS for
>> sharing Fusion virtual machines, iTunes library, iPhoto libraries etc.
>> without any issues.
> 
> Excellent; what OS is your NFS server running?

OpenSolaris snv129

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

Re: [zfs-discuss] file recovery on lost RAIDZ array

[Michael Eskowitz]

I'm sorry to say that I am quite the newbie to ZFS.  When you say zfs 
send/receive what exactly are you referring to?

I had the zfs array mounted to a specific location in my file system 
(/mnt/Share) and I was sharing that location over the network with a samba 
server.  The directory had read-write-execute persion set to allow anyone to 
write to it and I was copying data from windows into it.

At what point do file changes get committed to the file system?  I sort of 
assumed that any additional files copied over would be committed once the next 
file began copying.

Thanks for your insight.

-Mike



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

Re: [zfs-discuss] When Zpool has no space left and no snapshots

[Scott Meilicke]

Preemptively use quotas?


On 9/22/10 7:25 PM, "Aleksandr Levchuk"  wrote:

> Dear ZFS Discussion,
> 
> I ran out of space, consequently could not rm or truncate files. (It
> make sense because it's a copy-on-write and any transaction needs to
> be written to disk. It worked out really well - all I had to do is
> destroy some snapshots.)
> 
> If there are no snapshots to destroy, how to prepare for a situation
> when a ZFS pool looses it's last free byte?
> 
> Alex
> ___
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


--
Scott Meilicke | Enterprise Systems Administrator | Crane Aerospace &
Electronics | +1 425-743-8153 | M: +1 206-406-2670



We value your opinion!  How may we serve you better? 
Please click the survey link to tell us how we are doing:
http://www.craneae.com/ContactUs/VoiceofCustomer.aspx
Your feedback is of the utmost importance to us. Thank you for your time.

Crane Aerospace & Electronics Confidentiality Statement:
The information contained in this email message may be privileged and is 
confidential information intended only for the use of the recipient, or any 
employee or agent responsible to deliver it to the intended recipient. Any 
unauthorized use, distribution or copying of this information is strictly 
prohibited 
and may be unlawful. If you have received this communication in error, please 
notify 
the sender immediately and destroy the original message and all attachments 
from 
your electronic files.

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

[zfs-discuss] When Zpool has no space left and no snapshots

[Aleksandr Levchuk]

Dear ZFS Discussion,

I ran out of space, consequently could not rm or truncate files. (It
make sense because it's a copy-on-write and any transaction needs to
be written to disk. It worked out really well - all I had to do is
destroy some snapshots.)

If there are no snapshots to destroy, how to prepare for a situation
when a ZFS pool looses it's last free byte?

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

Re: [zfs-discuss] drive speeds etc

[Miles Nordin]

> "sb" == Simon Breden  writes:

sb> WD itself does not recommend them for 'business critical' RAID
sb> use

The described problems with WD aren't okay for non-critical
development/backup/home use either.  The statement from WD is nothing
but an attempt to upsell you, to differentiate the market so they can
tap into the demand curve at multiple points, and to overload you with
information so the question becomes ``which WD drive should I buy''
instead of ``which manufactuer's drive should I buy.''  Don't let this
stuff get a foothold inside your brain.

``mixing'' drives within a stripe is a good idea because it protects
you from bad batches and bad models/firmwares, which are not rare in
recent experience!  I always mix drives and included WD in that mix up
until this latest rash of problems.  ``mixing'' is only bad (for WD)
because it makes it easier for you, the customer, to characterize the
green performance deficit and notice the firmware bugs that are unique
to the WD drives.


pgpg2mRMPLVGG.pgp
Description: PGP signature
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] drive speeds etc

[Roy Sigurd Karlsbakk]

- Original Message -
> Regarding vdevs and mixing WD Green drives with other drives, you
> might find it interesting that WD itself does not recommend them for
> 'business critical' RAID use - this quoted from the WD20EARS page here
> (http://www.wdc.com/en/products/Products.asp?DriveID=773):

With TLER easily enabled on WD Black drives, I guess that's where we'll go. 
Anyway - this is a test box used for its purpose (testing), but it's still 
interesting to see these differences. Thanks for your input!

Vennlige hilsener / Best regards

roy
--
Roy Sigurd Karlsbakk
(+47) 97542685
r...@karlsbakk.net
http://blogg.karlsbakk.net/
--
I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er 
et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av 
idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og 
relevante synonymer på norsk.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] Jeff Bonwick leaves Sun/Oracle

[Eugen Leitl]

http://blogs.sun.com/bonwick/en_US/entry/and_now_page_2 

Monday Sep 27, 2010

And now, page 2

To my team:

After 20 incredible years at Sun/Oracle, I have decided to try something new.

This was a very hard decision, and not one made lightly.  I have always enjoyed 
my work, and still do -- everything from MTS-2 to Sun Fellow to Oracle VP.  I 
love the people I work with and the technology we've created together, which is 
why I've been doing it for so long.  But I have always wanted to try doing a 
startup, and recently identified an opportunity that I just can't resist.  (We 
are in stealth mode, so that's all I can say for now.)

This team will always have a special place in my heart.  Being part of the 
Solaris team means doing the Right Thing, innovating, changing the rules, and 
being thought leaders -- creating the ideas that everyone else wants to copy. 
Add to that Oracle's unmatched market reach and ability to execute, and you 
have a combination that I believe will succeed in ways we couldn't have 
imagined two years ago.  I hope that Solaris and ZFS Storage are wildly 
successful, and that you have fun making it happen.

To the ZFS community:

Thank you for being behind us from Day One.  After a decade in the making, ZFS 
is now an adult.  Of course there's always more to do, and from this point 
forward, I look forward to watching you all do it.  There is a great quote 
whose origin I have never found: "Your ideas will go further if you don't 
insist on going with them."  That has proven correct many times in my life, and 
I am confident that it will prove true again.

For me, it's time to try the Next Big Thing.  Something I haven't fully fleshed 
out yet.  Something I don't fully understand yet.  Something way outside my 
comfort zone.  Something I might fail at.  Everything worth doing begins that 
way.  I'll let you know how it goes.

My last day at Oracle will be this Thursday, September 30, 2010.  After that 
you can reach me at my personal mac.com e-mail, with the usual first-dot-last 
construction.

It has truly been a wonderful couple of decades.  To everyone who taught me, 
worked with me, learned from me, and supported my efforts in countless ways 
large and small:  Thank you.

-- 
Eugen* Leitl http://leitl.org";>leitl http://leitl.org
__
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] drive speeds etc

[Simon Breden]

Regarding vdevs and mixing WD Green drives with other drives, you might find it 
interesting that WD itself does not recommend them for 'business critical' RAID 
use - this quoted from the WD20EARS page here 
(http://www.wdc.com/en/products/Products.asp?DriveID=773):


Desktop / Consumer RAID Environments - WD Caviar Green Hard Drives are tested 
and recommended for use in consumer-type RAID applications (i.e., Intel Matrix 
RAID technology).*

*Business Critical RAID Environments – WD Caviar Green Hard Drives are not 
recommended for and are not warranted for use in RAID environments utilizing 
Enterprise HBAs and/or expanders and in multi-bay chassis, as they are not 
designed for, nor tested in, these specific types of RAID applications. For all 
Business Critical RAID applications, please consider WD’s Enterprise Hard 
Drives that are specifically designed with RAID-specific, time-limited error 
recovery (TLER), are tested extensively in 24x7 RAID applications, and include 
features like enhanced RAFF technology and thermal extended burn-in testing.


Further reading:
http://breden.org.uk/2009/05/01/home-fileserver-a-year-in-zfs/#drives
http://opensolaris.org/jive/thread.jspa?threadID=121871&tstart=0
http://jmlittle.blogspot.com/2010/03/wd-caviar-green-drives-and-zfs.html 
(mixing WD Green & Hitachi)
-- 
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] drive speeds etc

[Marty Scholes]

Roy Sigurd Karlsbakk wrote:
> device r/s w/s kr/s kw/s wait actv svc_t %w %b 
> cmdk0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 
> cmdk1 0.0 163.6 0.0 20603.7 1.6 0.5 12.9 24 24 
> fd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 
> sd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 
> sd1 0.5 140.3 0.3 2426.3 0.0 1.0 7.2 0 14 
> sd2 0.0 138.3 0.0 2476.3 0.0 1.5 10.6 0 18 
> sd3 0.0 303.9 0.0 2633.8 0.0 0.4 1.3 0 7 
> sd4 0.5 306.9 0.3 2555.8 0.0 0.4 1.2 0 7 
> sd5 1.0 308.5 0.5 2579.7 0.0 0.3 1.0 0 7 
> sd6 1.0 304.9 0.5 2352.1 0.0 0.3 1.1 1 7 
> sd7 1.0 298.9 0.5 2764.5 0.0 0.6 2.0 0 13 
> sd8 1.0 304.9 0.5 2400.8 0.0 0.3 0.9 0 6 

Something is going on with how these writes are ganged together.  The first two 
drives average 17KB per write and the other six 8.7KB per write.

The aggregate statistics listed show less of a disparity, but one still exists.

I have to wonder if there is some "max transfer length" type of setting on each 
drive which is different, allowing the Hitachi drives to allow larger 
transfers, resulting in fewer I/O operations, each having a longer service time.

Just to avoid confusion, the svc_t field it "service time" and not "seek time." 
 The service time is the total time to service a request, including seek time, 
controller overhead, time for the data to transit the SATA bus and time to 
write the data.  If the requests are larger, all else being equal, the service 
time will ALWAYS be higher, but that does NOT imply the drive is slower.  On 
the contrary, it often implies a faster drive which can service more data per 
request.

At any rate, there is a reason that the Hitachi drives are handling larger 
requests than the WD drives.  I glanced at the code for a while but could not 
figure out where the max transfer size is determined or used.
-- 
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 flash issue

[Cindy Swearingen]

Ketan,

Someone with more flash archive experience that me says that you
can't install a ZFS root flash archive with live upgrade at this
time. Duh, I knew that.

Sorry for the red herring... :-)

Cindy



On 09/28/10 08:30, Cindy Swearingen wrote:

Hi Ketan,

My flash archive experience is minimal, but..

This error suggest that the disk components of this pool might have some
SVM remnants. Is that possible? I would check with the metastat command,
review /etc/vfstab, or /etc/lu/ICF.* to see if they are referencing
meta devices.

Thanks,

Cindy

On 09/28/10 03:20, Ketan wrote:
I have created a solaris9 zfs root flash archive for sun4v environment 
which i 'm tryin to use for upgrading solaris10 u8 zfs root based 
server using live upgrade.


following is my current system status

lustatus
Boot Environment   Is   Active ActiveCanCopy
Name   Complete NowOn Reboot Delete Status
--  -- - -- --
zfsBE  yes  yesyes   no -
zfsBEu9yes  no noyes-



when i try to upgrade the with luupgrade i get following error


luupgrade -f -n zfsBEu9 -s /mnt -a /flash/zfsBEu9.flar

63521 blocks
miniroot filesystem is 
Mounting miniroot at 
Validating the contents of the media .
The media is a standard Solaris media.
Validating the contents of the miniroot .
Locating the flash install program.
Checking for existence of previously scheduled Live Upgrade requests.
Constructing flash profile to use.
Creating flash profile for BE .
Performing the operating system flash install of the BE .
CAUTION: Interrupting this process may leave the boot environment 
unstable or unbootable.

ERROR: The flash install failed; pfinstall returned these diagnostics:

ERROR: Field 2 - Invalid disk name (zfsBEu9)
The Solaris flash install of the BE  failed.


What could be the reason for this .. is there anything i 'm not doin k ?

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

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

Re: [zfs-discuss] ZFS flash issue

[Cindy Swearingen]

Hi Ketan,

My flash archive experience is minimal, but..

This error suggest that the disk components of this pool might have some
SVM remnants. Is that possible? I would check with the metastat command,
review /etc/vfstab, or /etc/lu/ICF.* to see if they are referencing
meta devices.

Thanks,

Cindy

On 09/28/10 03:20, Ketan wrote:

I have created a solaris9 zfs root flash archive for sun4v environment which i 
'm tryin to use for upgrading solaris10 u8 zfs root based server using live 
upgrade.

following is my current system status 



lustatus
Boot Environment   Is   Active ActiveCanCopy
Name   Complete NowOn Reboot Delete Status
--  -- - -- --
zfsBE  yes  yesyes   no -
zfsBEu9yes  no noyes-



when i try to upgrade the with luupgrade i get following error 




luupgrade -f -n zfsBEu9 -s /mnt -a /flash/zfsBEu9.flar

63521 blocks
miniroot filesystem is 
Mounting miniroot at 
Validating the contents of the media .
The media is a standard Solaris media.
Validating the contents of the miniroot .
Locating the flash install program.
Checking for existence of previously scheduled Live Upgrade requests.
Constructing flash profile to use.
Creating flash profile for BE .
Performing the operating system flash install of the BE .
CAUTION: Interrupting this process may leave the boot environment unstable or 
unbootable.
ERROR: The flash install failed; pfinstall returned these diagnostics:

ERROR: Field 2 - Invalid disk name (zfsBEu9)
The Solaris flash install of the BE  failed.


What could be the reason for this .. is there anything i 'm not doin k ?

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

[zfs-discuss] ZFS Issues and cpu panics

[Tony MacDoodle]

Hello,

We have been running into a few issues recently with cpu panics while trying
to reboot the control/service domains on various T-series platforms. Has
anyone seen the message below?

Thanks

SunOS Release 5.10 Version Generic_142900-03 64-bit
Copyright 1983-2009 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
NOTICE: zfs_parse_bootfs: error 6
Cannot mount root on rpool/44 fstype zfs

panic[cpu0]/thread=180e000: vfs_mountroot: cannot mount root

0180b950 genunix:vfs_mountroot+358 (800, 200, 0, 18a9800, 18d2000,
1901000)
%l0-3: 010d1400 010d14e0 018af1b8 01204000
%l4-7: 01204000 01903400 0600 0200
0180ba10 genunix:main+9c (0, 180c000, 185ede0, 182b768, 1831bb8,
18f3800)
%l0-3: 0180c000 0180c000 70002000 
%l4-7: 01866400  0180c000 0001

skipping system dump - no dump device configured
rebooting...

WARNING: Unable to update LDOM Variable
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] drive speeds etc

[Casper . Dik]

>I have both EVDS and EARS 2TB green drive.  And I have to say they are
>not good to build storage servers.


I think both have native 4K sectors; as such, they balk or perform slowly
when a smaller I/O or an unaligned IOP hits them.

How are they formatted? Specifically, solaris slices must be aligned on a 
4K boundary or performance will stink.

Casper

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

Re: [zfs-discuss] drive speeds etc

[Fei Xu]

I have both EVDS and EARS 2TB green drive.  And I have to say they are not good 
to build storage servers.

EVDS has compatibility issue with my supermicro appliance.  it will hang when 
doing huge data send or copy.  from IOSTAT I can see the data throughput is 
stuck on green disks with extremely high wait time.

for EARS drives, they are ok running opensolaris but veryvery poor performance 
handling small files.  I'm doing SVN via NFS share and it takes triple time CO 
a repository compare to NEtapp FAS960.  but the issue could be resolved by 
adding SSD as log device.  notice that, green disk seek time is 15ms and normal 
7200RPM disk is around 8.5ms.
I'll try the link provided by Christian to see if it can help the performance.

anyway, I've decided to use seagate 7200.11 which is big enough and fast.
-- 
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] Intermittent ZFS hang

[Robin Axelsson]

I am using a zpool for swap that is located in the rpool (i.e. not in the 
storage pool). The system disk contains four primary partitions where the first 
contains the system volume (c7d0s0) two are windows partitions (c7d0p2 and 
c7d0p3) and the fourth (c7d0p4) is a zfs pool dedicated for VirtualBox. The 
swap is located in c7d0s0 as rpool/swap. 'swap -l' returns 
swapfile devswaplo   blocks free
/dev/zvol/dsk/rpool/swap 182,2 8  4192248  4169344

I'm not sure how to make a raw slice for the swap file, it doesn't look like it 
is possible unless I get a separate hard drive for it. The swap area is not 
located in the storage pool so I'm not sure how this could cause interference 
with access to this pool.

I will upgrade to OpenIndiana (snv_b147 or later) as soon as I get a 
confirmation that it is not less stable than b134.
-- 
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] Intermittent ZFS hang

[Robin Axelsson]

I have now run some hardware tests as suggested by Cindy.'iostat -En' indicates 
no errors, i.e. after carefully checking the output from this command, all 
errors are followed by zeroes.

The only messages found in /var/adm/messages are the following:

 opensolaris scsi: [ID 365881 kern.info] 
/p...@0,0/pci1002,5...@b/pci1000,3...@0 (mpt0):
 opensolaris Log info 0x3108 received for target 3.
 opensolaris scsi_status=0x0, ioc_status=0x804b, scsi_state=0x0

 opensolaris scsi: [ID 365881 kern.info] 
/p...@0,0/pci1002,5...@b/pci1000,3...@0 (mpt0):
 opensolaris Log info 0x3108 received for target 3.
 opensolaris scsi_status=0x0, ioc_status=0x804b, scsi_state=0x1

and 

 opensolaris scsi: [ID 365881 kern.info] 
/p...@0,0/pci1002,5...@b/pci1000,3...@0 (mpt0):
 opensolaris Log info 0x3108 received for target 3.
 opensolaris scsi_status=0x0, ioc_status=0x804b, scsi_state=0x2

Where the difference between them is "scsi_state=0x0", "scsi_state=0x1" and 
"scsi_state=0x2" respectively. These messages are generated almost every second 
in the log and the most common one is the "scsi_state=0x0" message.

Grepping for any of the disks in the pools returns nothing from the 'fmdump 
-eV' command.

Also note that I have never used de-dup in any of these pools.
-- 
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] Intermittent ZFS hang

[James C. McPherson]

On 28/09/10 09:22 PM, Robin Axelsson wrote:

I also have this problem on my system which consists of an AMD Phenom 2
X4 with system pools on various hard drives connected to the SB750
controller and a larger raidz2 storage pool connected to an LSI 1068e
controller (using IT mode). The storage pool is also used to share
files using CIFS. The build of the OSOL is 134 and the system pools use
zpool v22. But the storage pool still uses zpool v14 from the original
2009.06 release of OSOL.

I have not encountered any errors or intermittent freezes in any of
these pools until I started using VirtualBox 4.2.8. The virtual
machines have been set up to access the storage pool via vboxsrv. When
doing various activities in a virtual machine that involves heavier
disk access (such as playing/streaming video, using bittorrent, etc)
via vboxsrv I also get this intermittent freeze of the zpool stack. The
rest of the system works fine (including the virtual machine) as long
as it doesn't involve access to the storage pool (I have not yet tried
accessing other pools during this freeze). It is easily seen on the
system monitor when the network access suddenly drops to zero for a few
minutes. Issuing commands such as 'zpool status' makes the ssh/bash
shell freeze until the zpool wakes up again. No errors are reported
when issuing the 'zpool status' command and all pools are 'ONLINE'. I
could give more exhaustive details from hardware scans as suggested in
this thread if that is desired...



Two possibilities:
(1) you're using ZFS vols for swap - these had some performance
improvements in builds after 134. If you can reconfigure to
use a raw slice (or two) instead that would help.


(2) 6908360 49.3% snv_129 vdb407_nvSeqWriteBs128kFs1g_zfs-raidz 
performance regression x86

which was fixed in snv_135.


James C. McPherson
--
Oracle
http://www.jmcp.homeunix.com/blog
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Intermittent ZFS hang

[Robin Axelsson]

I also have this problem on my system which consists of an AMD Phenom 2 X4 with 
system pools on various hard drives connected to the SB750 controller and a 
larger raidz2 storage pool connected to an LSI 1068e controller (using IT 
mode). The storage pool is also used to share files using CIFS. The build of 
the OSOL is 134 and the system pools use zpool v22. But the storage pool still 
uses zpool v14 from the original 2009.06 release of OSOL.

I have not encountered any errors or intermittent freezes in any of these pools 
until I started using VirtualBox 4.2.8. The virtual machines have been set up 
to access the storage pool via vboxsrv. When doing various activities in a 
virtual machine that involves heavier disk access (such as playing/streaming 
video, using bittorrent, etc) via vboxsrv I also get this intermittent freeze 
of the zpool stack. The rest of the system works fine (including the virtual 
machine) as long as it doesn't involve access to the storage pool (I have not 
yet tried accessing other pools during this freeze). It is easily seen on the 
system monitor when the network access suddenly drops to zero for a few 
minutes. Issuing commands such as 'zpool status' makes the ssh/bash shell 
freeze until the zpool wakes up again. No errors are reported when issuing the 
'zpool status' command and all pools are 'ONLINE'. I could give more exhaustive 
details from hardware scans as suggested in this thread if that 
 is desired...
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] ZFS flash issue

[Ketan]

I have created a solaris9 zfs root flash archive for sun4v environment which i 
'm tryin to use for upgrading solaris10 u8 zfs root based server using live 
upgrade.

following is my current system status 


lustatus
Boot Environment   Is   Active ActiveCanCopy
Name   Complete NowOn Reboot Delete Status
--  -- - -- --
zfsBE  yes  yesyes   no -
zfsBEu9yes  no noyes-



when i try to upgrade the with luupgrade i get following error 



luupgrade -f -n zfsBEu9 -s /mnt -a /flash/zfsBEu9.flar

63521 blocks
miniroot filesystem is 
Mounting miniroot at 
Validating the contents of the media .
The media is a standard Solaris media.
Validating the contents of the miniroot .
Locating the flash install program.
Checking for existence of previously scheduled Live Upgrade requests.
Constructing flash profile to use.
Creating flash profile for BE .
Performing the operating system flash install of the BE .
CAUTION: Interrupting this process may leave the boot environment unstable or 
unbootable.
ERROR: The flash install failed; pfinstall returned these diagnostics:

ERROR: Field 2 - Invalid disk name (zfsBEu9)
The Solaris flash install of the BE  failed.


What could be the reason for this .. is there anything i 'm not doin k ?
-- 
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] drive speeds etc

[Christian Kühnke]

Hi,
the question is which WD Green drives you are using. WDxxEADS or WDxxEARS. The 
WDxxEARS have a 4k physical sector size instead of 512B. You need some special 
trickery to get the max performance out of them, probably even more so in a 
raidz configuration.

See 
http://www.solarismen.de/archives/4-Solaris-and-the-new-4K-Sector-Disks-e.g.-WDxxEARS-Part-1.html
 and the following parts.

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