[zfs-discuss] Re: single memory allocation in the ZFS intent log

[Anton B. Rang]

Hi Mitchell,

I do work for Sun, but I don't consider myself biased towards the slab 
allocator or any other Solaris or Sun code. I know we've got plenty of 
improvements to make!

That said, your example is not multi-threaded. There are two major performance 
issues which come up with a list structure in a multi-threaded environment. The 
slab allocator addresses both of these.

The first is locking. In a multi-threaded environment, your 
node_alloc/node_free would have to lock the free list head. This leads to 
contention between threads. (Yes, I know about lockfree algorithms, but they 
don't eliminate contention; and they are even more susceptible to the second 
problem.)

The second is cache line movement. Each time a CPU reads the memory location 
containing the head of the free list, it needs to get this data from memory or 
from another CPU's cache. Each time the CPU updates memory (which happens for 
each allocation or free), the cache line must be invalidated in all other CPU's 
caches. Hence ownership of the cache line moves between CPUs. This is 
incredibly expensive (it’s a major reason that locking is slow, actually). It 
can take tens to hundreds of cycles.

How does the slab allocator avoid these? By taking advantage of the operating 
system's providing a “current CPU” index to the thread. The allocator uses this 
to index into a set of cached objects which have been recently freed by the 
current CPU, and allocates/frees into that set. This has the advantages that 
(a) the lock protecting the set is very rarely contended, since a thread would 
have to be pre-empted during the run of the allocator to have its current CPU 
change; (b) the data structures describing the set are not shared between CPUs 
and hence can stay in one cache; (c) the objects themselves tend to have been 
freed from the current CPU and hence are somewhat more likely to be in the 
current CPU's cache. (I'm not sure if that last has a measurable effect.)

If you’re interested in learning more, I’d suggest reading the original paper, 
which you can find at:

  http://citeseer.ist.psu.edu/bonwick94slab.html

The slab allocator does somewhat more, such as allowing objects of a type which 
require initialization to be reused more cheaply than an 
allocation+initialization, but the above are the key scalability insights as I 
understand them.

Your approach will certainly perform better on a single processor, and might on 
a dual processor. Beyond that, it's scalability is likely poor. And, as Casper 
pointed out, keeping private memory pools for each subsystem tends to increase 
kernel memory usage .
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] Re: Unbootable system recovery

[Ewen Chan]

In the instructions, it says that the system retains a copy of the zpool cache 
in /etc/zfs/zpool.cache.

It also said that when the system boots up, it looks to that to try and mount 
the pool, so to get out of the panic-reboot look, it said to delete that file.

Well, I retained a copy of it before I deleted it.

Would looking at the contents of that file help to determine what's what? Or 
would it help in trying to fix/resolve the problem that I am experiencing?
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] Re: Re: Unbootable system recovery

[Akhilesh Mritunjai]

Hi,

Like what matt said, unless there is a bug in code, zfs should automatically 
figure out the drive mappings. The real problem as I see is using 16 drives in 
single raidz... which means if two drives malfunction, you're out of luck. 
(raidz2 would survive 2 drives... but still I believe 16 drives is too much).

May I suggest you re-check the cabling as drive going bad might be related to 
that... or even changing the power supply (I got burnt that way). It might just 
be an intermittent drive malfunction. You might also surface scan the drives 
and rule out bad sectors.

Good luck :)

PS: When you get your data back, do switch to raidz2 or mirrored config that 
can survive loss of more than 1 disk. My experience (which is not much) shows 
it doesn't take much to render more than one disk out of 20 or so... especially 
when moving them.

- Akhilesh
 
 
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] A versioning FS

[Frank Cusack]

On October 5, 2006 7:02:29 PM -0700 Chad Lewis <[EMAIL PROTECTED]> wrote:


On Oct 5, 2006, at 6:48 PM, Frank Cusack wrote:


On October 5, 2006 5:25:17 PM -0700 David Dyer-Bennet <[EMAIL PROTECTED]
b.net> wrote:

Well, unless you have a better VCS than CVS or SVN.  I first met this
as an obscure, buggy, expensive, short-lived SUN product, actually; I
believe it was called NSE, the Network Software Engineering
environment.  And I used one commercial product (written by an NSE
user after NSE was discontinued) that supported the feature needed.
Both of these had what I might call a two-level VCS.  Each developer
had one or more private repositories (the way people have working
directories now with SVN), but you had full VCS checkin/checkout (and
compare and rollback and so forth) within that.  Then, when your code
was ready for the repository, you did a "commit" step that pushed it
up from your private repository to the public repository.


I wouldn't call that 2-level, it's simply branching, and all VCS/SCM
systems have this, even rcs.  Some expose all changes in the private
branch to everyone (modulo protection mechanisms), some only expose
changes
that are "put back" (to use Sun teamware terminology).

Both CVS and SVN have this.

-frank



David is describing a different behavior. Even a branch is still  ultimately on 
the single,
master server with CVS, SVN, and more other versioning systems.  Teamware, and 
a few
other versioning systems, let you have more arbitrary parent and  child 
relationships.


How are branches not arbitrary parent and child relationships?  (except
in cvs where branches pretty much suck but still it's close)


A Teamware putback really isn't a matter of exposure. Until you do a  putback 
to the
parent, the code is not physically (or even logically) present in the  parent.


That is what I meant by exposure -- whether or not "private" code is
available to others.  But how does that matter?

The difference between teamware (or git or bk or mercurial) and cvs (or
svn or p4) here is that everyone can see all private branches and everyone
can see each change in a private branch (again, modulo protections).
That doesn't matter to the main branch.  The code is not in the main
branch logically (physically doesn't matter) until you integrate or
putback.

My point is that having a private branch, where you can check in changes
to your heart's content, and re-branch at will, and don't have to follow
"must compile" rules, can be handled by most any VCS.  Which is what
David was saying is needed for it to replace the functionality of a
versioned filesystem.

Some of them (eg p4) handle branching much better than others, making
this easier, but all of them can do it.

Wow, I'm surprised teamware doesn't have changelists or a similar concept.
Talk about stone ages. :-)

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

Re: [zfs-discuss] A versioning FS

[Chad Lewis]

On Oct 5, 2006, at 6:48 PM, Frank Cusack wrote:

On October 5, 2006 5:25:17 PM -0700 David Dyer-Bennet <[EMAIL PROTECTED] 
b.net> wrote:

Well, unless you have a better VCS than CVS or SVN.  I first met this
as an obscure, buggy, expensive, short-lived SUN product, actually; I
believe it was called NSE, the Network Software Engineering
environment.  And I used one commercial product (written by an NSE
user after NSE was discontinued) that supported the feature needed.
Both of these had what I might call a two-level VCS.  Each developer
had one or more private repositories (the way people have working
directories now with SVN), but you had full VCS checkin/checkout (and
compare and rollback and so forth) within that.  Then, when your code
was ready for the repository, you did a "commit" step that pushed it
up from your private repository to the public repository.


I wouldn't call that 2-level, it's simply branching, and all VCS/SCM
systems have this, even rcs.  Some expose all changes in the private
branch to everyone (modulo protection mechanisms), some only expose  
changes

that are "put back" (to use Sun teamware terminology).

Both CVS and SVN have this.

-frank



David is describing a different behavior. Even a branch is still  
ultimately on the single,
master server with CVS, SVN, and more other versioning systems.  
Teamware, and a few
other versioning systems, let you have more arbitrary parent and  
child relationships.


In Teamware, you can create a project gate, have a variety of people  
check code into this
project gate, and do all of this without ever touching the parent  
gate. When the
project is done, you then checkin the changes to the project gate's  
parent.


The gate parent may itself be a child of some other gate, making the  
above
project gate a grand-child of some higher gate. You can also change a  
child's parent,
so you could in fact skip the parent and go straight to the "grand"  
parent if you wish.


For that matter, you can re-parent the "parent" to sync with the  
former child if you

had some reason to do so.

A Teamware putback really isn't a matter of exposure. Until you do a  
putback to the
parent, the code is not physically (or even logically) present in the  
parent.


Teamware's biggest drawbacks are a lack of change sets (like how  
Subversion tracks
simultaneous, individual changes as a group) and that it only runs  
via file access

(no network protocol, filesystem or NFS only.)

Mercurial seems to be similar to Teamware in terms of parenting, but  
with network protocol

support builtin. Which is presumably OpenSolaris will be using it.

ckl


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

Re: [zfs-discuss] A versioning FS

[Chad Leigh -- Shire.Net LLC]

On Oct 5, 2006, at 7:47 PM, Chad Leigh -- Shire.Net LLC wrote:

I find the "unix" conventions of storying a file and file~ or any  
of the other myriad billion ways of doing it that each app has  
invented to be much more unwieldy.



sorry,  "storing" a file, not "storying"

---
Chad Leigh -- Shire.Net LLC
Your Web App and Email hosting provider
chad at shire.net





smime.p7s
Description: S/MIME cryptographic signature
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] A versioning FS

[Frank Cusack]

On October 5, 2006 5:25:17 PM -0700 David Dyer-Bennet <[EMAIL PROTECTED]> wrote:

Well, unless you have a better VCS than CVS or SVN.  I first met this
as an obscure, buggy, expensive, short-lived SUN product, actually; I
believe it was called NSE, the Network Software Engineering
environment.  And I used one commercial product (written by an NSE
user after NSE was discontinued) that supported the feature needed.
Both of these had what I might call a two-level VCS.  Each developer
had one or more private repositories (the way people have working
directories now with SVN), but you had full VCS checkin/checkout (and
compare and rollback and so forth) within that.  Then, when your code
was ready for the repository, you did a "commit" step that pushed it
up from your private repository to the public repository.


I wouldn't call that 2-level, it's simply branching, and all VCS/SCM
systems have this, even rcs.  Some expose all changes in the private
branch to everyone (modulo protection mechanisms), some only expose changes
that are "put back" (to use Sun teamware terminology).

Both CVS and SVN have this.

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

Re: [zfs-discuss] A versioning FS

[Chad Leigh -- Shire.Net LLC]

On Oct 5, 2006, at 5:40 PM, Erik Trimble wrote:

And, try thinking of a directory with a few dozen files in it, each  
with
a dozen or more versions. that's hideous, from a normal user  
standpoint.

VMS's implementation of ; is completely unwieldy if
you have more than a few files,


No it is not. I  worked for DEC and used VMS up through 1993 and  
never found it unwieldy.  Even if I had 100 versions of one file.  It is


1) what you are used to

2) what you are trained to do

that makes it unwieldy or not

I find the "unix" conventions of storying a file and file~ or any of  
the other myriad billion ways of doing it that each app has invented  
to be much more unwieldy.


Yes, you have to "purge" your directories once in a while. The same  
way you have to clean up any file "mess" you make on you computer  
(download area, desktop, etc).



or more than a few versions. And, in
modern typical use, it is _highly_ likely both will be true.


So what if you have more than a few versions of a file.

Beauty is in the eye of the beholder, and just because YOU find it  
unwieldy does not make it so for the general user or anyone else.


I would LOVE to have a VMS style (sorry, my TOPS-20 usage was very  
little so I have no remembrance of it there) file versioning built in  
to the system.


"save early, save often" ONLY makes sense with a file versioning  
system, or else you lose previous edits if you decide you have gone  
down a wrong alley.


Chad

---
Chad Leigh -- Shire.Net LLC
Your Web App and Email hosting provider
chad at shire.net





smime.p7s
Description: S/MIME cryptographic signature
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] A versioning FS

[Wee Yeh Tan]

On 10/6/06, David Dyer-Bennet <[EMAIL PROTECTED]> wrote:

One of the big problems with CVS and SVN and Microsoft SourceSafe is
that you don't have the benefits of version control most of the time,
because all commits are *public*.


David,

That is exactly what "branch" is for in CVS and SVN.  Dunno much about
M$ SourceSafe.

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

Re: [zfs-discuss] single memory allocation in the ZFS intent log

[Erblichs]

Casper Dik,

After my posting, I assumed that a code question should be
directed to the ZFS code alias, so I apologize to the people
show don't read code. However, since the discussion is here,
I will post a code proof here. Just use "time program" to get
a generic time frame. It is under 0.1 secs for 500k loops
(each loop does removes a obj and puts it back).

It is just to be used as a proof of concept that a simple
pre-alloc'ed set of objects can be accessed so much faster
than allocating and assigning them.

To support the change to the intent log objects, I would suggest
first identiying the number of objects normally allocated and
use that as a working set of objects. A time element is also
needed to identify when objects should be released from the
free list to the memory cache. Yes, the initial thoughts of
having a per CPU based allocs are coded in which would allow
multiple simultaneious access to a freelist per CPU. This
should remove most of the mutex code necessary for scalability.

Objective
---
   What this app code is proving is that items that are pre-alloc'ed
can be removed off a simple free list and stored on a free list.
This is just a inception proof that shows "fast access" to a
working set of objects.

   The time to make one chunk alloc, place all of them on a
free list, and then perform 500k ops of removal and insertions
is probably somewhere 50 to 1000x faster than even the best memory
allocators allocating/retrieving 500k items. If a dynamic list of
nodes are required the chunk alloc should be changed.

  This quick piece of app prog runs in less than 0.1 sec with 500k
retrieves and store ops. This is fast enough to grab 64byte chunks
dealing with even a 1Gb Eth link. Even though this code is simplified,
it
indicates that kmem_allocs will have the same benefits even without
sleeping.

-

The code does a single pre alloc and then breaks up the alloc
into N node pieces. It takes each piece and places them
on a free list in the init section. The assumption here is
that we have a fixed reasonable number of items. If the
number of items is dynamic the init could easily alloc
a number of nodes, then use watermarks to alloc and free
into / from the free list as the number of nodes are used.

If the logic is used to deal with kmem ops, then any free
nodes could be returned to memory as excess nodes are in
the free list.

The base level of this type of logic is normally used when
a special program project requires non-standard interfaces
to guarantee a HIGH level of performance.

The main has a hard code of 500k loops, which allocs one
node and then frees it. Thus, 500k equiv allocs would need
to be done. This ran in the 0.02 to 0.35 secs on a 1.3GHz
laptop Linux box.

-

It is my understanding that the Bonwicks's new allocator was created
to remove fragmentation. And yes it also allows the OS to reduce the
overhead of of dealing with mem objects of process's that 
are freed and alloc'ed frequently. When the system gets low on
memory, it steals freed objects that are being cached. However,
even with no SLEEPING, I have yet to see it perform as fast as 
simple retrieves and stores.

Years ago, the amount of memory on a system was limited due to
its expense. This is no longer the case. Some/most 
processes/threads could have a decent increase in performance
if the amount of workload done
on a working set of objects is minimized. Up to this workset,
I propose that a almost guranteed level of performance could
be achieved.

With the comment that any type of functionality that has merits
get a API so multiple processes / threads can use that
functionality. Years ago I was in the "process" of doing that
when I left a company with a ARC group. It was to add a layer
of working set mem objects that would have "fast access" properties.

I will ONLY GUARANTEE that X working set objects once freed 
to the FREE LIST can be re-allocated without waiting for the objects. 
Any count beyond that working set, has the same underlying properties. 
Except if I KNOW
that the number on my freelist goes down to a small value, I could
pre-request more objects. The latency of retrieving these objects
could thus be minimized.

This logic then removes on demand memory allocations, so any WAIT
time MAY not effect the other parts of the process that need more
 

Re: [zfs-discuss] Versioning in ZFS: Do we need it?

[Wee Yeh Tan]

Jeremy,

The intended use of both are vastly different.

A snapshot is a point-in-time image of a file system that as you have
pointed out, may have missed several versions of changes regardless of
frequency.

Versioning (ala VAX -- ok, I feel old now) keeps versions of every
changes up to a specified limit.  It cannot be used to construct a
point-in-time image so is pretty useless in a restore situation.

For most cases where it matters, version control systems should be
used.  They may be a little less wieldy than automatic FS versioning
but affords better control (with features like
branching/merging/concurrent access).

So, back to the advantage of versioning FS vs frequent ZFS snapshot,
there is no other advantages than you have stated.  Versioning FS
gives you exactly that 1 feature.  ZFS snapshots may approximate this
behaviour but it will not be as efficient or convenient.


--
Just me,
Wire ...

On 10/6/06, Jeremy Teo <[EMAIL PROTECTED]> wrote:

What would versioning of files in ZFS buy us over a "zfs snapshots +
cron" solution?

I can think of one:

1. The usefulness of the ability to get the prior version of anything
at all (as richlowe puts it)

Any others?
--
Regards,
Jeremy
___
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] A versioning FS

[Erik Trimble]

On Thu, 2006-10-05 at 17:25 -0700, David Dyer-Bennet wrote:
> 
> Well, unless you have a better VCS than CVS or SVN.  I first met this
> as an obscure, buggy, expensive, short-lived SUN product, actually; I
> believe it was called NSE, the Network Software Engineering
> environment.  And I used one commercial product (written by an NSE
> user after NSE was discontinued) that supported the feature needed.
> Both of these had what I might call a two-level VCS.  Each developer
> had one or more private repositories (the way people have working
> directories now with SVN), but you had full VCS checkin/checkout (and
> compare and rollback and so forth) within that.  Then, when your code
> was ready for the repository, you did a "commit" step that pushed it
> up from your private repository to the public repository.
> 
> One of the big problems with CVS and SVN and Microsoft SourceSafe is
> that you don't have the benefits of version control most of the time,
> because all commits are *public*.

Just FYI:  that buggy, expensive, short-lived SUN product eventually
became "Teamware". 

Check out (no pun intended)  Mercurial and similar products, which have
similar behavior to Teamware - each developer has a "workspace" for
code, and you can do VC inside that workspace without having to do a
putback into the "main" tree.  That way, you do frequent VC checkins,
but don't putback to the main tree until things actually work. Or, at
least, you _claim_ them to work. 

:-)




-- 
Erik Trimble
Java System Support
Mailstop:  usca14-102
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

Fwd: [zfs-discuss] solaris-supported 8-port PCI-X SATA controller

[David Dyer-Bennet]

Jason asked me to forward his reply on to the list, so here it is.

Thanks, Jason, for the specifics!  Very specific answers seem to be
what's needed in this situation.

-- Forwarded message --
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Oct 5, 2006 11:50 AM
Subject: Re: [zfs-discuss] solaris-supported 8-port PCI-X SATA controller
To: David Dyer-Bennet <[EMAIL PROTECTED]>


I am not able to directly reply to the list for some reason but the
only one that is supported
with the Marvell driver at this point is this one:

http://www.8anet.com/merchant.ihtml?pid=2655&lastcatid=129&step=4

I bough a different one myself only to find out that it had an older
revision of the chip that had
some serious issues.  The driver requires C0 or better.

If you want a 2 card 4 port solution I am curently using a 4 port
Si3114 PCI card purchased from
newegg:

http://www.newegg.com/Product/Product.asp?Item=N82E16815124020

You do have to flash the bios on this one with the IDE bios for the
3114 from SiliconImage because
the class code on the raid bios makes Solaris unable to see it.
Pretty cheap to get 8 ports for
$40 plus tax/shipping.  The only real issue I had was with 2+ cards I
ran out of real mode memory
because each card loaded it's own version of it's bios.  The easy
solution was to set the PCI
slots that the card is installed in to not scan for option roms.
Solaris will still see and load
the driver for the card you just wont be able to boot from it.
Chances are good that if your
motherboard has PCI-X slots it will have the capability of disabling
the option rom scan.

Let me know if you have any other questions.  Also, please forward my
reply to the aliases for
other to see.

Jason


I've lucked into some big disks, so I'm thinking of biting the bullet

(screaming loudly in the process) and superceding the SATA controllers
on my motherboard with something that will work with hot-swap in
Solaris.  (did I mention before I'm still pissed about this?) I have
enough to populate all 8 bays (meaning adding 4 disks to what I have
now), so the 6 ports on the motherboard don't quite cover it anyway,
and getting hotswap working was kind of the point of spending $2000 on
the new server.

But, as always, the problem is in finding a controller that Solaris
supports, including hotswap.  The last guy I remember going through
this here ended up still scrod because the board he got had a -7
instead of -9 variant of the controller chip and it *still* didn't
work.

I might be able to use 2 4-port boards; I'm not absolutely sure I have
2 PCI-X slots (I'm away from home this week).

So can the combined wisdom of these lists point me to an exact vendor
and part-number of a PCI-X board for an AMD Opteron system that
Solaris supports SATA and hot-swap with?  Note I said "vendor"; I'd
like to know that the batch a vendor has actually works with Solaris,
since it seems fairly random whether any particular batch does or not.
 At least 4-port, preferably 8-port.  And, of course, very cheap :-).
I'm currently running snv_44, and don't expect to drop backwards a lot
from there.  If I need to add an available driver or configure tables
or something, cool (but I'll need pointers to what needs to be done);
I don't insist that it work out-of-the-box, just that I be able to get
it working.
--
David Dyer-Bennet, , 
RKBA: 
Pics: 
Dragaera/Steven Brust: 
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss






--
David Dyer-Bennet, , 
RKBA: 
Pics: 
Dragaera/Steven Brust: 
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] A versioning FS

[David Dyer-Bennet]

A lot of this we're clearly not going to agree on and I've said what I
had to contribute.  There's one remaining point, though...

On 10/5/06, Erik Trimble <[EMAIL PROTECTED]> wrote:

On Thu, 2006-10-05 at 16:08 -0700, David Dyer-Bennet wrote:



> Actually, "save early and often" is exactly why versioning is
> important.  If you discover you've gone down a blind alley in some
> code, it makes it easy to get back to the earlier spots.  This, in my
> experience, happens at a detail level where you won't (in fact can't)
> be doing checkins to version control.

Then, IMHO, you aren't using VC properly.  File Versioning should NEVER,
EVER, EVER be used for anything around VC.  It might be useful for
places VC isn't traditionally use (Office documents, small scripts,
etc.), but the example you provide is one which is easily solved by use
of frequent checkins to VC - indeed, that's what VC is supposed to be
for.


No, any sane VC protocol must specifically forbid the checkin of the
stuff I want versioning (or file copies or whatever) for.  It's
partial changes, probably doesn't compile, nearly certainly doesn't
work.  This level of work product *cannot* be committed to the
repository.

Well, unless you have a better VCS than CVS or SVN.  I first met this
as an obscure, buggy, expensive, short-lived SUN product, actually; I
believe it was called NSE, the Network Software Engineering
environment.  And I used one commercial product (written by an NSE
user after NSE was discontinued) that supported the feature needed.
Both of these had what I might call a two-level VCS.  Each developer
had one or more private repositories (the way people have working
directories now with SVN), but you had full VCS checkin/checkout (and
compare and rollback and so forth) within that.  Then, when your code
was ready for the repository, you did a "commit" step that pushed it
up from your private repository to the public repository.

One of the big problems with CVS and SVN and Microsoft SourceSafe is
that you don't have the benefits of version control most of the time,
because all commits are *public*.
--
David Dyer-Bennet, , 
RKBA: 
Pics: 
Dragaera/Steven Brust: 
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] A versioning FS

[Brian Hechinger]

On Thu, Oct 05, 2006 at 04:40:09PM -0700, Erik Trimble wrote:
> 
> So, here's a question:  if I delete file X;1, do I delete X;x ?  That
> is, do I delete all versions of a file when I delete the actual file?
> what about deleting a (non-head) version?  And, exactly how many

Under VMS at least, that is entirely up to you, you can delete X;1, X;2 or
X;* if you so desire.

> different files have to be cleaned up when you logout?  How does this
> get configured? Who does the configuring? What if I _want_ versions of
> some files, but not the others?  

That is where it gets tricky.  Under the DEC !UNIX OSes, file versioning was
just a way of life since it was on all the time for everyone, period.  Trying
to apply that to UNIX, where file versionioning previously didn't exist?  Not
so easy. ;)

> And, what about network-sharing?  For non-interactive use?  (i.e. via
> SAMBA, or other apps where you're not looking at the FS via a command
> prompt?)

A way to not allow those access to the versioning system sounds reasonable.

> File versioning is really only useful when we can hide the versioning
> mess from the end-user, and yet provide them with some reasonable
> mechanism for accessing the file versions if need be. And we keep
> versions around, period. I don't see that as being possible using the
> traditional UNIX/POSIX filesystem layout.  Like I said before, maybe
> when the FS becomes a RDBMS, but even then...

The way digital did it is spot on, however, the use of ; is a problem once
you apply UNIX/POSIX filesystem requirements to it.  It may not work.

On the other hand ODS *is* an RDBMS really, so. ;)

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

Re: [zfs-discuss] A versioning FS

[Erik Trimble]

On Thu, 2006-10-05 at 16:08 -0700, David Dyer-Bennet wrote:
> On 10/5/06, Erik Trimble <[EMAIL PROTECTED]> wrote:
> 
> > Doing versioning at the file-system layer allows block-level changes to
> > be stored, so it doesn't consume enormous amounts of extra space. In
> > fact, it's more efficient than any versioning software (CVS, SVN,
> > teamware, etc) for storing versions.
> 
> Comparing to cvs/svn misses the point; as I said, they address
> comletely different needs.
> 
I was making a general point, to make it clear FS versioning isn't a
disk pig.


> > However, there are three BIG drawbacks for using versioning in your FS
> > (that assumes that it is a tunable parameter and can be turned off for a
> > FS when not desired):
> >
> > (1)  File listing symantics become a bit of a mess.  VMS stores versions
> > as ;That is, it uses the semi-colon as a
> > divider.  Now, I'm not at all sure how we can make ZFS POSIX-compliant
> > and still do something like this.  Versioning filesystems tend to be a
> > complete mess - it is hard to present usable information about which
> > versions are available, and at the same time keep things clean. Even
> > keeping versions in a hidden dir (say .zfs_versions) in each directory
> > still leaves that directory filled with a huge mess of files.
> 
> "Complete mess" is certainly not my experience (I worked with TOPS-20
> from 1977 to 1985 and VMS from 1979 to 1985).  The key is that you
> need to *clean up*; specifically, you need to use the command which
> deletes all but the most recent copy of each file in a directory at
> the end of pretty much each work session.
> 
> It's trivial to present information on which versions are available;
> you simply list each one as a file, which has the date info any file
> has, and the version number.
> 

I stand by the "complete mess" statement. _You_ have trained yourself to
get around the problem, by eliminating most of the reason for file
versioning - you delete everything when you log out.  A normal user (or
even, most scripts) aren't going to do this. Indeed, I would argue that
it makes no sense to implement versioning if all you are going to use it
for is on a per-session basis. 

And, try thinking of a directory with a few dozen files in it, each with
a dozen or more versions. that's hideous, from a normal user standpoint.
VMS's implementation of ; is completely unwieldy if
you have more than a few files, or more than a few versions. And, in
modern typical use, it is _highly_ likely both will be true. 


> > (2)  File Versioning is no replacement for source code control, as you
> > miss all the extra features (tagging, branching, comments, etc) that go
> > with a file version check-in.
> 
> It's very definitely not an alternative or replacement for source code
> control, no.  It provides a very useful feature to use *alongside*
> source control.  Source code control is also not a replacement for
> file versioning (I end up creating spare copies of files with funny
> names for things I'd otherwise get from versioning; and I end up
> losing time through not having through to create such a file, whereas
> versioning is automatic).

File versioning would certainly be nice in many cases, but I think it's
better implemented in the application (think of Photoshop's unlimited
undo feature, though better than that), than in the FS, where it creates
a whole lot of clutter and confusion real fast, where it is only
specifically useful for a very limited selection of files.


> > (3)  Many apps continuously save either temp copies or actual copies of
> > the file you are working on. This leads to a version explosion, where
> > you end up with 100s of versions of a commonly used file.  This tends to
> > be worse than useless, as people have an incredibly hard time figuring
> > out which (older) version they might actually want to look at.  And,
> > this problem ISN'T ever going to go away, as it would require apps to
> > understand filesystem features for ZFS, which isn't going to happen.
> 
> Files treated that way are often deleted at the end of the session
> automatically, so no problem there.  Or else they'll be cleaned up
> when you do your session-end cleanup.  What the heck was that command
> on TOPS-20 anyway?  Maybe "purge"?  Sorry, 20-year-old memories are
> fuzzy on some details.

So, here's a question:  if I delete file X;1, do I delete X;x ?  That
is, do I delete all versions of a file when I delete the actual file?
what about deleting a (non-head) version?  And, exactly how many
different files have to be cleaned up when you logout?  How does this
get configured? Who does the configuring? What if I _want_ versions of
some files, but not the others?  

And, what about network-sharing?  For non-interactive use?  (i.e. via
SAMBA, or other apps where you're not looking at the FS via a command
prompt?)

> File versioning worked a lot better on TOPS-20 than on VMS, as I
> remember it.  The facility looked the same, but actually w

[zfs-discuss] solaris-supported 8-port PCI-X SATA controller

[David Dyer-Bennet]

I've lucked into some big disks, so I'm thinking of biting the bullet
(screaming loudly in the process) and superceding the SATA controllers
on my motherboard with something that will work with hot-swap in
Solaris.  (did I mention before I'm still pissed about this?) I have
enough to populate all 8 bays (meaning adding 4 disks to what I have
now), so the 6 ports on the motherboard don't quite cover it anyway,
and getting hotswap working was kind of the point of spending $2000 on
the new server.

But, as always, the problem is in finding a controller that Solaris
supports, including hotswap.  The last guy I remember going through
this here ended up still scrod because the board he got had a -7
instead of -9 variant of the controller chip and it *still* didn't
work.

I might be able to use 2 4-port boards; I'm not absolutely sure I have
2 PCI-X slots (I'm away from home this week).

So can the combined wisdom of these lists point me to an exact vendor
and part-number of a PCI-X board for an AMD Opteron system that
Solaris supports SATA and hot-swap with?  Note I said "vendor"; I'd
like to know that the batch a vendor has actually works with Solaris,
since it seems fairly random whether any particular batch does or not.
At least 4-port, preferably 8-port.  And, of course, very cheap :-).
I'm currently running snv_44, and don't expect to drop backwards a lot
from there.  If I need to add an available driver or configure tables
or something, cool (but I'll need pointers to what needs to be done);
I don't insist that it work out-of-the-box, just that I be able to get
it working.
--
David Dyer-Bennet, , 
RKBA: 
Pics: 
Dragaera/Steven Brust: 
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] A versioning FS

[Brian Hechinger]

On Thu, Oct 05, 2006 at 04:08:13PM -0700, David Dyer-Bennet wrote:
>
> when you do your session-end cleanup.  What the heck was that command
> on TOPS-20 anyway?  Maybe "purge"?  Sorry, 20-year-old memories are
> fuzzy on some details.

It's PURGE under VMS, so knowing DEC, it was named PURGE under TOPS-20
as well.

H, gotta get the DECsystem-2020 powered up one of these days.

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

Re: [zfs-discuss] A versioning FS

[David Dyer-Bennet]

On 10/5/06, Erik Trimble <[EMAIL PROTECTED]> wrote:


Doing versioning at the file-system layer allows block-level changes to
be stored, so it doesn't consume enormous amounts of extra space. In
fact, it's more efficient than any versioning software (CVS, SVN,
teamware, etc) for storing versions.


Comparing to cvs/svn misses the point; as I said, they address
comletely different needs.


However, there are three BIG drawbacks for using versioning in your FS
(that assumes that it is a tunable parameter and can be turned off for a
FS when not desired):

(1)  File listing symantics become a bit of a mess.  VMS stores versions
as ;That is, it uses the semi-colon as a
divider.  Now, I'm not at all sure how we can make ZFS POSIX-compliant
and still do something like this.  Versioning filesystems tend to be a
complete mess - it is hard to present usable information about which
versions are available, and at the same time keep things clean. Even
keeping versions in a hidden dir (say .zfs_versions) in each directory
still leaves that directory filled with a huge mess of files.


"Complete mess" is certainly not my experience (I worked with TOPS-20
from 1977 to 1985 and VMS from 1979 to 1985).  The key is that you
need to *clean up*; specifically, you need to use the command which
deletes all but the most recent copy of each file in a directory at
the end of pretty much each work session.

It's trivial to present information on which versions are available;
you simply list each one as a file, which has the date info any file
has, and the version number.


(2)  File Versioning is no replacement for source code control, as you
miss all the extra features (tagging, branching, comments, etc) that go
with a file version check-in.


It's very definitely not an alternative or replacement for source code
control, no.  It provides a very useful feature to use *alongside*
source control.  Source code control is also not a replacement for
file versioning (I end up creating spare copies of files with funny
names for things I'd otherwise get from versioning; and I end up
losing time through not having through to create such a file, whereas
versioning is automatic).


(3)  Many apps continuously save either temp copies or actual copies of
the file you are working on. This leads to a version explosion, where
you end up with 100s of versions of a commonly used file.  This tends to
be worse than useless, as people have an incredibly hard time figuring
out which (older) version they might actually want to look at.  And,
this problem ISN'T ever going to go away, as it would require apps to
understand filesystem features for ZFS, which isn't going to happen.


Files treated that way are often deleted at the end of the session
automatically, so no problem there.  Or else they'll be cleaned up
when you do your session-end cleanup.  What the heck was that command
on TOPS-20 anyway?  Maybe "purge"?  Sorry, 20-year-old memories are
fuzzy on some details.

File versioning worked a lot better on TOPS-20 than on VMS, as I
remember it.  The facility looked the same, but actually working with
it was much cleaner and easier.

Making it somewhat controllable would be useful.  Starting with maybe
an inheritable default, so some directory trees could be set not to
version.


I'd discourage File Versioning at this late stage in UNIX.  Source Code
control systems fulfill the need for serious uses, and casual usage is
obviated by the mantra of "save early, save often" that has been beaten
into the userbase. Trying to change that is a recipe for disaster.


Actually, "save early and often" is exactly why versioning is
important.  If you discover you've gone down a blind alley in some
code, it makes it easy to get back to the earlier spots.  This, in my
experience, happens at a detail level where you won't (in fact can't)
be doing checkins to version control.
--
David Dyer-Bennet, , 
RKBA: 
Pics: 
Dragaera/Steven Brust: 
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] A versioning FS

[Casper . Dik]

>Brian Hechinger wrote:
>> On Thu, Oct 05, 2006 at 11:19:19AM -0700, David Dyer-Bennet wrote:
>>> On 10/5/06, Jeremy Teo <[EMAIL PROTECTED]> wrote:
 What would a version FS buy us that cron+ zfs snapshots doesn't?
>>> Finer granularity; no chance of missing a change.
>>>
>>> TOPS-20 did this, and it was *tremendously* useful . Snapshots, source
>>> control, and other alternatives aren't, in fact, alternatives.
>>> They're useful in and of themselves, very useful indeed, but they
>>> don't address the same needs as versioning.
>> 
>> VMS _still_ does this, and it's one of my favorite features of the OS.
>
>It is a real PITA if you are unfortunate enough to use quotas :-(

It's one of the things I hated about VMS; so I quickly wrote a script
which on logout purged all extra copies and renamed all files back to
*;1.

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

Re: [zfs-discuss] A versioning FS

[Richard Elling - PAE]

Brian Hechinger wrote:

On Thu, Oct 05, 2006 at 11:19:19AM -0700, David Dyer-Bennet wrote:

On 10/5/06, Jeremy Teo <[EMAIL PROTECTED]> wrote:

What would a version FS buy us that cron+ zfs snapshots doesn't?

Finer granularity; no chance of missing a change.

TOPS-20 did this, and it was *tremendously* useful . Snapshots, source
control, and other alternatives aren't, in fact, alternatives.
They're useful in and of themselves, very useful indeed, but they
don't address the same needs as versioning.


VMS _still_ does this, and it's one of my favorite features of the OS.


It is a real PITA if you are unfortunate enough to use quotas :-(
 -- richard
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] A versioning FS

[Erik Trimble]

Brian Hechinger wrote:

On Thu, Oct 05, 2006 at 11:19:19AM -0700, David Dyer-Bennet wrote:
  

On 10/5/06, Jeremy Teo <[EMAIL PROTECTED]> wrote:


What would a version FS buy us that cron+ zfs snapshots doesn't?
  

Finer granularity; no chance of missing a change.

TOPS-20 did this, and it was *tremendously* useful . Snapshots, source
control, and other alternatives aren't, in fact, alternatives.
They're useful in and of themselves, very useful indeed, but they
don't address the same needs as versioning.



VMS _still_ does this, and it's one of my favorite features of the OS.

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

I too remember VMS and the FS versioning feature.

Doing versioning at the file-system layer allows block-level changes to 
be stored, so it doesn't consume enormous amounts of extra space. In 
fact, it's more efficient than any versioning software (CVS, SVN, 
teamware, etc) for storing versions.


However, there are three BIG drawbacks for using versioning in your FS 
(that assumes that it is a tunable parameter and can be turned off for a 
FS when not desired):


(1)  File listing symantics become a bit of a mess.  VMS stores versions 
as ;That is, it uses the semi-colon as a 
divider.  Now, I'm not at all sure how we can make ZFS POSIX-compliant 
and still do something like this.  Versioning filesystems tend to be a 
complete mess - it is hard to present usable information about which 
versions are available, and at the same time keep things clean. Even 
keeping versions in a hidden dir (say .zfs_versions) in each directory 
still leaves that directory filled with a huge mess of files.


(2)  File Versioning is no replacement for source code control, as you 
miss all the extra features (tagging, branching, comments, etc) that go 
with a file version check-in.


(3)  Many apps continuously save either temp copies or actual copies of 
the file you are working on. This leads to a version explosion, where 
you end up with 100s of versions of a commonly used file.  This tends to 
be worse than useless, as people have an incredibly hard time figuring 
out which (older) version they might actually want to look at.  And, 
this problem ISN'T ever going to go away, as it would require apps to 
understand filesystem features for ZFS, which isn't going to happen.



I'd discourage File Versioning at this late stage in UNIX.  Source Code 
control systems fulfill the need for serious uses, and casual usage is 
obviated by the mantra of "save early, save often" that has been beaten 
into the userbase. Trying to change that is a recipe for disaster.


Maybe when we change filesystems to a DB, we can look at automatic 
versioning again, as a DB can mitigate #1 and #3 issues above, and can 
actually implement #2 completely.   OracleFS, here I come. ()


-Erik


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

Re: [zfs-discuss] A versioning FS

[Brian Hechinger]

On Thu, Oct 05, 2006 at 11:19:19AM -0700, David Dyer-Bennet wrote:
> On 10/5/06, Jeremy Teo <[EMAIL PROTECTED]> wrote:
> >What would a version FS buy us that cron+ zfs snapshots doesn't?
> 
> Finer granularity; no chance of missing a change.
> 
> TOPS-20 did this, and it was *tremendously* useful . Snapshots, source
> control, and other alternatives aren't, in fact, alternatives.
> They're useful in and of themselves, very useful indeed, but they
> don't address the same needs as versioning.

VMS _still_ does this, and it's one of my favorite features of the OS.

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

Re: [zfs-discuss] Re: Re: Unbootable system recovery

[Matthew Ahrens]

Ewen Chan wrote:

However, in order for me to lift the unit, I needed to pull the
drives out so that it would actually be moveable, and in doing so, I
think that the drive<->cable<->port allocation/assignment has
changed.


If that is the case, then ZFS would automatically figure out the new 
mapping.  (Of course, there could be an undiscovered bug in that code.)


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

[zfs-discuss] Re: Re: Unbootable system recovery

[Ewen Chan]

well...let me give a little bit of background.

I built the system with a 4U, 16 drive rackmount enclosure; without a 
backplane. Originally, I thought that I wouldn't really need one because I was 
going to have 16 cables running around anyways.

Once everything was in place, and AFTER, I had transferred my data to the 
system; then I decided that I was going to move it into my room (and out of the 
living room where I was doing the build).

However, in order for me to lift the unit, I needed to pull the drives out so 
that it would actually be moveable, and in doing so, I think that the 
drive<->cable<->port allocation/assignment has changed.

If there is a way for me to figure out which drive is supposed to go to which 
port (as reported by ZFS and/or Solaris), than also in theory, I should be able 
to figured out what goes where, and it would have been like as if nothing 
changed.

The problem is I don't know what that map(ping) is.

The other thing is that the documentation doesn't really exactly tell you what 
steps you should do to recover from something like that. It just says you 
should re-initialize the drives. 

My hope is that someone, SOMEWHERE, would be able to have some suggestions as 
to what I can do from here, other than crying about the lost data, biting the 
bullet, and reinstalling the OS from scratch again.

(whether it'd be here, on OpenSolaris, ZFS, Jeff Bonwick (and his team), Bill 
Moore (and his team) -- I just think that with over 200 million tests, that 
someone would have tried that and been through what I'm going through now, and 
knows what needs/should be done at this point in order for safe data recovery 
and bring the pool back online.)

If there's a way to find out the original drive mapping, then I can try and see 
if I can slowly replicate that to bring the pool back online.

(I do remember that when I was doing the OS install, that the drives on the aac 
wasn't listed in sequential order, it was ..t7, then..t9, t2, t8, etc.. (I 
don't recall what it was exactly of course, and I don't know why it wouldn't 
scan it sequentially)).
 
 
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] Re: directory tree removal issue with zfs on Blade 1500/PC rack server IDE disk

[Matthew Ahrens]

Stefan Urbat wrote:

By the way, I have to wait a few hours to umount and check mountpoint
permissions, because an automated build is currently running on that
zfs --- the performance of [EMAIL PROTECTED] is indeed rather poor (much worse
than ufs), but this is another, already documented and bug entry
"honoured" issue.


Really?  Are you allowing ZFS to use the entire disk (and thus turn on 
the disk's write cache)?  Can you describe your workload and give 
numbers on both ZFS and UFS?  What bug was filed?


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

Re: [zfs-discuss] Re: Unbootable system recovery

[Matthew Ahrens]

Ewen Chan wrote:

::status

debugging crash dump vmcore.0 (64-bit) from unknown
operating system: 5.10 Generic_118855-14 (i85pc)
panic message:
assertion failed: 0 == dmu_buf_hold_array(os, object, offset, size, FALSE, FTAG, 
&numbufs, &dbp), file : ../../common/fs/zfs/dmu.c, line: 366
dump content: kernel pages only

::stack

vpanic()
0xfb9ad0f3()
dmu_write+0x127()
space_map_sync+0x1ee()
metaslab_sync+0xfa()
vdev_sync+0x50()
spa_sync+0x10e()
txg_sync_thread+0x115()


It would appear that some critical metadata was damaged.  Since you 
appear to be using a single (16-wide!) raid-z group, this could happen 
if there are failures on two devices (despite the fact that we store 
multiple copies of all critical metadata).


In this situation it may not be possible to recover your data.

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

Re: [zfs-discuss] What's going to make it into 11/06?

[Matthew Ahrens]

Darren Dunham wrote:

What about "ZFS root"?. And compatibility with Live Upgrade?. Any
timetable estimation?.


ZFS root has been previously announced as targeted for update 4.


ZFS root support will most likely not be available in Solaris 10 until 
update 5.  (And of course this is subject to change...)


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

Re: [zfs-discuss] zfs mirror resurrection

[Richard Elling - PAE]

Dick Davies wrote:

Need a bit of help salvaging a perfectly working ZFS
mirror that I've managed to render unbootable.

I've had a ZFS root (x86, mirored zpool, SXCR b46 ) working fine for 
months.


I very foolishly decided to mirror /grub using SVM
(so I could boot easily if a disk died). Shrank swap partitions
to make somewhere to keep the SVM database (2 copies on each
disk).


D'oh!
N.B. this isn't needed, per se, just make a copy of /grub and
the boot loader.


Rebooted and everything seemed ok. I booted with the
second disk unplugged and SVM didn't seem to come up.
ZFS showed the pool as degraded, as expected.

Unplugged the first disk, tried another boot.
Got as far as detecting the disks, then hangs.

So the question -
How do I get rid of SVM from a zfs root system?


The key change is in /etc/system where the rootfs is
specified as the metadevice rather than the real device.

N.B. if you only have 2 disks, then the test you performed
will not work for SVM.
 -- richard
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] Re: Unbootable system recovery

[Ewen Chan]

(with help from Robert)

Yes, there are files.

# pwd
/var/crash/FILESERVER
# ls -F
boundsunix.0unix.1 vmcore.0 vmcore.1
# mdb 0
Loading modules: [ unix krtld genunix specfs dtrace cpu.AuthenticAMD.15 ufs ip 
sctp usba fctl nca lofs random zfs nfs sppp ptm cpc fcip ]
> ::status
debugging crash dump vmcore.0 (64-bit) from unknown
operating system: 5.10 Generic_118855-14 (i85pc)
panic message:
assertion failed: 0 == dmu_buf_hold_array(os, object, offset, size, FALSE, 
FTAG, &numbufs, &dbp), file : ../../common/fs/zfs/dmu.c, line: 366
dump content: kernel pages only
> ::stack
vpanic()
0xfb9ad0f3()
dmu_write+0x127()
space_map_sync+0x1ee()
metaslab_sync+0xfa()
vdev_sync+0x50()
spa_sync+0x10e()
txg_sync_thread+0x115()
> $http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] A versioning FS

[David Dyer-Bennet]

On 10/5/06, Jeremy Teo <[EMAIL PROTECTED]> wrote:

What would a version FS buy us that cron+ zfs snapshots doesn't?


Finer granularity; no chance of missing a change.

TOPS-20 did this, and it was *tremendously* useful . Snapshots, source
control, and other alternatives aren't, in fact, alternatives.
They're useful in and of themselves, very useful indeed, but they
don't address the same needs as versioning.
--
David Dyer-Bennet, , 
RKBA: 
Pics: 
Dragaera/Steven Brust: 
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] re: ZFS snapshot for running oracle instance

[James Foronda]

Zhisong Jin wrote:
would it possible to use ZFS snapshot as way 
to doing hot backup for oracle database? 
anybody have tried that? 


Yes, it works very well as long as you follow the usual hot backup 
procedure then replace the portion where you do an OS-level copy with 
ZFS snapshot.  Very cool. :)


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

Re: [zfs-discuss] What's going to make it into 11/06?

[Darren Dunham]

> What about "ZFS root"?. And compatibility with Live Upgrade?. Any
> timetable estimation?.

ZFS root has been previously announced as targeted for update 4.

-- 
Darren Dunham   [EMAIL PROTECTED]
Senior Technical Consultant TAOShttp://www.taos.com/
Got some Dr Pepper?   San Francisco, CA bay area
 < This line left intentionally blank to confuse you. >
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] What's going to make it into 11/06?

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Cindy Swearingen wrote:
> See the previous posting about this below.
> 
> You can read about these features in the ZFS Admin Guide.

I miss the "can remove a vdev if there is enough free space to move data
around" :-(.

What about "ZFS root"?. And compatibility with Live Upgrade?. Any
timetable estimation?.

11/06 will be a fairly worthwhile upgrade, by the way.

- --
Jesus Cea Avion _/_/  _/_/_/_/_/_/
[EMAIL PROTECTED] http://www.argo.es/~jcea/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/  _/_/_/_/_/
   _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRSU+xplgi5GaxT1NAQLYwwP/f83LsNFfzT5wqAs9kiHgKXi/rPjOkyUd
H8isAjXe6nW+sHuFcCiBMqYEYnx2GphV24QosqelOBoCC0WjzRgB99ulf9aYXto9
WhttgMMUBUP6KU6TIUsE4VN/1dafP6KuJLsHLbZ65Q5uQoOkME3s3QHPUNrYpQh3
CXtQX9oEnzY=
=8XE9
-END PGP SIGNATURE-
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] What's going to make it into 11/06?

[Cindy Swearingen]

Hi Brian,

See the previous posting about this below.

You can read about these features in the ZFS Admin Guide.

Cheers,

Cindy


Subject: Solaris 10 ZFS Update
From: George Wilson <[EMAIL PROTECTED]>
Date: Mon, 31 Jul 2006 11:51:09 -0400
To: zfs-discuss@opensolaris.org

We have putback a significant number of fixes and features from 
OpenSolaris into what will become Solaris 10 11/06. For reference here's 
the list:


Features:
PSARC 2006/223 ZFS Hot Spares
6405966 Hot Spare support in ZFS
PSARC 2006/303 ZFS Clone Promotion
6276916 support for "clone swap"
PSARC 2006/388 snapshot -r
6373978 want to take lots of snapshots quickly ('zfs snapshot -r')

Bug Fixes:
4034947 anon_swap_adjust() should call kmem_reap() if availrmem is low.
6288488 du reports misleading size on RAID-Z
6366301 CREATE with owner_group attribute is not set correctly with 
NFSv4/ZFS

6385436 zfs set  returns an error, but still sets property value
6393490 libzfs should be a real library
6397148 fbufs debug code should be removed from buf_hash_insert()
6401400 zfs(1) usage output is excessively long
6409228 typo in aclutils.h
6409302 passing a non-root vdev via zpool_create() panics system
6415739 assertion failed: !(zio->io_flags & 0x00040)
6416482 filebench oltp workload hangs in zfs
6416759 ::dbufs does not find bonus buffers anymore
6416794 zfs panics in dnode_reallocate during incremental zfs restore
6417978 double parity RAID-Z a.k.a. RAID6
6421216 ufsrestore should use acl_set() for setting ACLs
6424554 full block re-writes need not read data in
6425111 detaching an offline device can result in import confusion
6425740 assertion failed: new_state != old_state
6430121 3-way deadlock involving tc_lock within zfs
6433264 crash when adding spare: nvlist_lookup_string(cnv, "path", 
&path) == 0

6433406 zfs_open() can leak memory on failure
6433408 namespace_reload() can leak memory on allocation failure
6433679 zpool_refresh_stats() has poor error semantics
6433680 changelist_gather() ignores libuutil errors
6433717 offline devices should not be marked persistently unavailble
6435779 6433679 broke zpool import
6436524 importing a bogus pool config can panic system
6436526 delete_queue thread reporting drained when it may not be true
6436800 ztest failure: spa_vdev_attach() returns EBUSY instead of ENOTSUP
6439102 assertain failed: dmu_buf_refcount(dd->dd_dbuf) == 2 in 
dsl_dir_destroy_check()

6439370 assertion failures possible in dsl_dataset_destroy_sync()
6440499 zil should avoid txg_wait_synced() and use dmu_sync() to issue 
parallel IOs when fsyncing

6444346 zfs promote fails in zone
6446569 deferred list is hooked on flintstone vitamins
6447377 ZFS prefetch is inconsistant
6447452 re-creating zfs files can lead to failure to unmount
6448371 'zfs promote' of a volume clone fails with EBUSY
6450292 unmount original file system, 'zfs promote' cause system panic.
6451124 assertion failed: rc->rc_count >= number
6451412 renaming snapshot with 'mv' makes unmounting snapshot impossible

Thanks,
George

Brian Hechinger wrote:

11/06 is just around the corner! What new ZFS features are going to
make it into that release?

-brian
___
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

[zfs-discuss] Versioning in ZFS: Do we need it?

[Jeremy Teo]

What would versioning of files in ZFS buy us over a "zfs snapshots +
cron" solution?

I can think of one:

1. The usefulness of the ability to get the prior version of anything
at all (as richlowe puts it)

Any others?
--
Regards,
Jeremy
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] re: ZFS snapshot for running oracle instance

[Ceri Davies]

On Thu, Oct 05, 2006 at 11:04:49AM -0400, Zhisong Jin wrote:
> would it possible to use ZFS snapshot as way 
> to doing hot backup for oracle database? 
> anybody have tried that? 

You would need to put the tablespaces with data files on the filesystem
being snapped into backup mode while you take the snapshot, but it
should work ok.

Ceri
-- 
That must be wonderful!  I don't understand it at all.
  -- Moliere


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

[zfs-discuss] re: ZFS snapshot for running oracle instance

[Zhisong Jin]

would it possible to use ZFS snapshot as way 
to doing hot backup for oracle database? 
anybody have tried that? 

Thanks.
Jason


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

[zfs-discuss] What's going to make it into 11/06?

[Brian Hechinger]

11/06 is just around the corner! What new ZFS features are going to
make it into that release?

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

Re: [zfs-discuss] A versioning FS

[Brian Hechinger]

On Thu, Oct 05, 2006 at 10:18:18PM +0800, Jeremy Teo wrote:
> What would a version FS buy us that cron+ zfs snapshots doesn't?

Instant file copy.  with cron you could make multiple changes between
snapshot runs.

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

[zfs-discuss] A versioning FS

[Jeremy Teo]

What would a version FS buy us that cron+ zfs snapshots doesn't?

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

[zfs-discuss] Crash when doing rm -rf

[Simon Lundström]

Not an really good subject, I know but that's kind of what happend.

I'm trying to build an backup-solution server, Windows users using OSCAR (which 
uses rsync) to sync their files to an folder and when complete takes a 
snapshot. It has worked before but then I turned on the -R switch to rsync and 
when I then removed the folder with rm -rf it crashed. I didn't save what the 
error that the shell gave me but I know is mentioned something about an colon 
(:).

I have no idea how to debug the Solaris kernel, I am both an ZFS and an Solaris 
newbie, but I've managed to gather some information that I've seen others 
pasting:

bash-3.00# mdb 0
Loading modules: [ unix krtld genunix specfs dtrace uppc pcplusmp scsi_vhci ufs 
ip sctp arp usba uhci nca lofs zfs random sppp ptm nfs crypto ipc md cpc fcip 
fctl fcp logindmux ]
> ::status
debugging crash dump vmcore.0 (32-bit) from unknown
operating system: 5.11 snv_48 (i86pc)
panic message:
ZFS: bad checksum (read on  off 0: zio dbbf8880 [L1 ZFS plain file] 
4000L/400P DVA[0]=<0:6aa000:800> DVA[1]=<0:b80a7000:800> fletcher4 lzjb LE 
contiguous birth=12316 fill=2 cksum=601eba85e8:
dump content: kernel pages only
> ::spa
ADDR STATE NAME
da9f5ac0ACTIVE backup
> ::memstat
Page SummaryPagesMB  %Tot
     
Kernel  41647   162   32%
Anon56673   221   44%
Exec and libs   11331449%
Page cache   2963112%
Free (cachelist)11554459%
Free (freelist)  4742184%

Total  128910   503
Physical   128909   503
> $C
db95bae4 vpanic(f9f95858, d7a91388, d7a913b8, f9f94660, 0, 0)
db95bc70 zio_done+0x122(dbbf8880)
db95bc8c zio_next_stage+0x66(dbbf8880)
db95bcac zio_wait_for_children+0x46(dbbf8880, 11, dbbf8a70)
db95bcc0 zio_wait_children_done+0x18(dbbf8880)
db95bcd8 zio_next_stage+0x66(dbbf8880)
db95bd10 zio_vdev_io_assess+0x11a(dbbf8880)
db95bd24 zio_next_stage+0x66(dbbf8880)
db95bd64 vdev_mirror_io_done+0x289(dbbf8880)
db95bd78 zio_vdev_io_done+0x25()
db95bdc8 taskq_thread+0x176(d430a290, 0)
db95bdd8 thread_start+8()

bash-3.00# zpool status -v
  pool: backup
 state: FAULTED
status: One or more devices could not be used because the the label is missing
or invalid.  There are insufficient replicas for the pool to continue
functioning.
action: Destroy and re-create the pool from a backup source.
   see: http://www.sun.com/msg/ZFS-8000-5E
 scrub: none requested
config:

NAMESTATE READ WRITE CKSUM
backup  UNAVAIL  0 0 0  insufficient replicas
  raidz1UNAVAIL  0 0 0  insufficient replicas
c0d1FAULTED  0 0 0  corrupted data
c1d0FAULTED  0 0 0  corrupted data
c1d1ONLINE   0 0 0

The most important stuff from /var/adm/messages:

Oct  5 14:02:39 unknown sshd[5421]: [ID 800047 auth.crit] fatal: Read from 
socket failed: Connection reset by peer
Oct  5 14:04:40 unknown unix: [ID 836849 kern.notice]
Oct  5 14:04:40 unknown ^Mpanic[cpu0]/thread=db95bde0:
Oct  5 14:04:40 unknown genunix: [ID 809409 kern.notice] ZFS: bad checksum 
(read on  off 0: zio dbbf8880 [L1 ZFS plain file] 4000L/400P 
DVA[0]=<0:6aa000:800> DVA[1]=<0:b80a7000:800> fletcher4 lzjb LE contiguous 
birth=12316 fill=2 
cksum=601eba85e8:408ce39c2ee8:172f0d844a20fa:5dfa8a1d4d38722): error 50
Oct  5 14:04:40 unknown unix: [ID 10 kern.notice]
Oct  5 14:04:40 unknown genunix: [ID 353471 kern.notice] db95bc70 
zfs:zio_done+122 (dbbf8880)
Oct  5 14:04:40 unknown genunix: [ID 353471 kern.notice] db95bc8c 
zfs:zio_next_stage+66 (dbbf8880)
Oct  5 14:04:40 unknown genunix: [ID 353471 kern.notice] db95bcac 
zfs:zio_wait_for_children+46 (dbbf8880, 11, dbbf8)
Oct  5 14:04:40 unknown genunix: [ID 353471 kern.notice] db95bcc0 
zfs:zio_wait_children_done+18 (dbbf8880)
Oct  5 14:04:40 unknown genunix: [ID 353471 kern.notice] db95bcd8 
zfs:zio_next_stage+66 (dbbf8880)
Oct  5 14:04:40 unknown genunix: [ID 353471 kern.notice] db95bd10 
zfs:zio_vdev_io_assess+11a (dbbf8880)
Oct  5 14:04:40 unknown genunix: [ID 353471 kern.notice] db95bd24 
zfs:zio_next_stage+66 (dbbf8880)
Oct  5 14:04:40 unknown genunix: [ID 353471 kern.notice] db95bd64 
zfs:vdev_mirror_io_done+289 (dbbf8880)
Oct  5 14:04:40 unknown genunix: [ID 353471 kern.notice] db95bd78 
zfs:zio_vdev_io_done+25 (dbbf8880, 0, 0, 0, )
Oct  5 14:04:40 unknown genunix: [ID 353471 kern.notice] db95bdc8 
genunix:taskq_thread+176 (d430a290, 0)
Oct  5 14:04:40 unknown genunix: [ID 353471 kern.notice] db95bdd8 
unix:thread_start+8 ()
Oct  5 14:04:40 unknown unix: [ID 10 kern.notice]
Oct  5 14:04:40 unknown genunix: [ID 672855 kern.notice] syncing file 
systems...Oct  5 14:04:40 unknown genuni

[zfs-discuss] Re: directory tree removal issue with zfs on Blade 1500/PC rack server IDE disk

[Stefan Urbat]

You were completely right in guessing the issue: after umount /export/home the 
ZFS residing there the wrong (?), but likely standard Solaris 10, not ufs 
affecting attribute mask was visible: 700. After changing this to 755 and 
mounting the ZFS thereon again, the issue was resolved completely. Thanks for 
the hint!
 
 
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] Unbootable system recovery

[Robert Milkowski]

Hello Ewen,

Thursday, October 5, 2006, 11:13:04 AM, you wrote:

Can you post at least panic info?

-- 
Best regards,
 Robertmailto:[EMAIL PROTECTED]
   http://milek.blogspot.com

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

[zfs-discuss] Unbootable system recovery

[Ewen Chan]

I have just recently (physically) moved a system with 16 hard drives (for the 
array) and 1 OS drive; and in doing so, I needed to pull out the 16 drives so 
that it would be light enough for me to lift.

When I plugged the drives back in, initially, it went into a panic-reboot loop. 
After doing some digging, I deleted the file /etc/zfs/zpool.cache.

When I try to import the pool using the zpool import command this is what I get:

# zpool import
pool: share
id: 10028139418536329530
state: ONLINE
action: The pool can be imported using its name or numeric identifier. The pool 
may be active on on another system, but can be imported using the '-f' flag.
config:

shareONLINE
raidz ONLINE
c0t0d0  ONLINE
...
c0t15d0 ONLINE

(total of 16 drives)

When I try to import the pool using the zpool import -f command, I end up 
getting the same system panic that I got before.

How can I re-initialize the devices, and what would the best for me to bring 
the pool back up and online, given that I do NOT have backups or a means to 
recover the data on there?
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] Re: directory tree removal issue with zfs on Blade 1500/PC rack server IDE disk

[Stefan Urbat]

> 
> >On 10/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> wrote:
> >- Should ZFS respect the umask setting even when it
> is creating the mountpoint?
> 
> 
> No  (I think this is being fixed).
> 

Nice to hear, this is a very strange phenomenon as told.

> >- Should Solaris (in general) ignore mountpoint
> permissions?
> 
> 
> Yes, I believe so.
> 
> Casper
>

I fully agree to this: I never encountered any comparable consequence of ill 
mountpoint permissions on any Unix: so I would expect a successful mount should 
always hide completely the original mountpoint permissions resp. render them 
irrelevant, only using the current, mounted file system permissions. 

By the way, I have to wait a few hours to umount and check mountpoint 
permissions, because an automated build is currently running on that zfs --- 
the performance of [EMAIL PROTECTED] is indeed rather poor (much worse than 
ufs), but this is another, already documented and bug entry "honoured" issue.
 
 
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] directory tree removal issue with zfs on Blade 1500/PC rack server IDE disk

[Casper . Dik]

>On 10/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Unmount all the ZFS filesystems and check the permissions on the mount
>> points and the paths leading up to them.
>
>I experienced the same problem and narrowed it down to that
>essentially, chdir("..") in "rm -rf" failed to ascend up the
>directory.  The mountpoint was created by ZFS but with the umask set
>to 077.
>
>- Should ZFS respect the umask setting even when it is creating the mountpoint?


No  (I think this is being fixed).

>- Should Solaris (in general) ignore mountpoint permissions?


Yes, I believe so.

Casper

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

Re: [zfs-discuss] directory tree removal issue with zfs on Blade 1500/PC rack server IDE disk

[Wee Yeh Tan]

On 10/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Unmount all the ZFS filesystems and check the permissions on the mount
points and the paths leading up to them.


I experienced the same problem and narrowed it down to that
essentially, chdir("..") in "rm -rf" failed to ascend up the
directory.  The mountpoint was created by ZFS but with the umask set
to 077.

- Should ZFS respect the umask setting even when it is creating the mountpoint?
- Should Solaris (in general) ignore mountpoint permissions?


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

Re: [zfs-discuss] directory tree removal issue with zfs on Blade 1500/PC rack server IDE disk

[Wee Yeh Tan]

Check the permission of your mountpoint after you unmount the dataset.
Most likely, you have something like rwx--.

On 10/5/06, Stefan Urbat <[EMAIL PROTECTED]> wrote:

I want to know, if anybody can check/confirm the following issue I observed 
with a fully patched Solaris 10 u2 with ZFS running on IDE disks and how the 
state of the IDE/ZFS issue is in general in the development of OpenSolaris 
resp. Nevada:

I have observed the following issue: when I try to remove with

rm -rf dir

a whole directory tree named dir, only the regular files will be removed on 
Solaris 10 u2 (2006/06) when doing so on a ZFS file system residing on an IDE 
disk, but not the sub directories --- it is okay, when doing the same command 
on a SCSI disk.

Details: the directory traversal is malfunctioning or out of sync with the IDE 
disk, I fear, because if I do the following afterwards

find dir -depth -exec rmdir {} \;

the remaining, now aside from sub directories empty directories are removed silently and 
successfully. And this is exactly okay when using the -depth option only, because this 
guarantees the "right" directory traversal, where the exec is applied only on 
the leaves first and afterwards on the higher nodes.

If I rm -rf as root it works too, but as normal user it doesn't, though the 
directory masks are okay (755 for the owning user trying to remove). The --- 
too generic --- error message is

rm: cannot determine if this is an ancestor of the current working directory

(in German(auf Deutsch): rm: Es kann nicht ermittelt werden, ob dies ein 
Vorgänger des aktuellen Arbeitsverzeichnisses ist:)

and I fear too, that this is an outcome of the already described IDE/ZFS issue 
in Solaris 10. But it is the strangest thing when trying to remove a directory 
tree I ever happened to see on Unix in 15 years experience and a truely nasty 
bug.

When I understand right, this should only affect PATA=IDE, but neither SCSI (as 
observed by myself) nor SATA (this is only assumed).


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




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

Re: [zfs-discuss] directory tree removal issue with zfs on Blade 1500/PC rack server IDE disk

[Casper . Dik]

>the remaining, now aside from sub directories empty directories are r=
>emoved silently and successfully. And this is exactly okay when using=
> the -depth option only, because this guarantees the "right" director=
>y traversal, where the exec is applied only on the leaves first and a=
>fterwards on the higher nodes.


This is probably caused by the mountpoint (the underlying directory, not
the root of the filesystem) being a mode like 500.


Unmount all the ZFS filesystems and check the permissions on the mount 
points and the paths leading up to them.

Casper

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

[zfs-discuss] directory tree removal issue with zfs on Blade 1500/PC rack server IDE disk

[Stefan Urbat]

I want to know, if anybody can check/confirm the following issue I observed 
with a fully patched Solaris 10 u2 with ZFS running on IDE disks and how the 
state of the IDE/ZFS issue is in general in the development of OpenSolaris 
resp. Nevada:

I have observed the following issue: when I try to remove with 

rm -rf dir

a whole directory tree named dir, only the regular files will be removed on 
Solaris 10 u2 (2006/06) when doing so on a ZFS file system residing on an IDE 
disk, but not the sub directories --- it is okay, when doing the same command 
on a SCSI disk.

Details: the directory traversal is malfunctioning or out of sync with the IDE 
disk, I fear, because if I do the following afterwards

find dir -depth -exec rmdir {} \;

the remaining, now aside from sub directories empty directories are removed 
silently and successfully. And this is exactly okay when using the -depth 
option only, because this guarantees the "right" directory traversal, where the 
exec is applied only on the leaves first and afterwards on the higher nodes.

If I rm -rf as root it works too, but as normal user it doesn't, though the 
directory masks are okay (755 for the owning user trying to remove). The --- 
too generic --- error message is

rm: cannot determine if this is an ancestor of the current working directory

(in German(auf Deutsch): rm: Es kann nicht ermittelt werden, ob dies ein 
Vorgänger des aktuellen Arbeitsverzeichnisses ist:)

and I fear too, that this is an outcome of the already described IDE/ZFS issue 
in Solaris 10. But it is the strangest thing when trying to remove a directory 
tree I ever happened to see on Unix in 15 years experience and a truely nasty 
bug.

When I understand right, this should only affect PATA=IDE, but neither SCSI (as 
observed by myself) nor SATA (this is only assumed).
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss