Re: [zfs-discuss] problem with zfs receive -i
On Sat, Aug 19, 2006 at 07:21:52PM -0700, Frank Cusack wrote: > On August 19, 2006 7:06:06 PM -0700 Matthew Ahrens <[EMAIL PROTECTED]> > wrote: > >My guess is that the filesystem is not mounted. It should be remounted > >after the 'zfs recv', but perhaps that is not happening correctly. You > >can see if it's mounted by running 'df' or 'zfs list -o name,mounted'. > > You are right, it's not mounted. > > >Did the 'zfs recv' print any error messages? > > nope. > > > Are you able to reproduce this behavior? > > easily. Hmm, I think there must be something special about your filesystems or configuration; I'm not able to reproduce it. One possible cause for trouble is if you are doing the 'zfs receive' into a filesystem which has descendent filesystems (eg, you are doing 'zfs recv pool/[EMAIL PROTECTED]' and pool/fs/child exists). This isn't handled correctly now, but you should get an error message in that case. (This will be fixed by some changes Noel is going to putback next week.) Could you send me the output of 'truss zfs recv ...', and 'zfs list' and 'zfs get -r all ' on both the source and destination systems? > ah ok. Note that if I do zfs send; zfs send -i on the "local side", then > do zfs list; zfs mount -a on the "remote side", I still show space used > in the @7.1 snapshot, even though I didn't touch anything. I guess mounting > accesses the mount point and updates the atime. Hmm, maybe. I'm not sure if that's exactly what's happening, because mounting and unmounting a filesystem doesn't seem to update the atime for me. Does the @7.1 snapshot show used space before you do the 'zfs mount -a'? > On the "local" side, how come after I take the 7.1 snapshot and then 'ls', > the 7.1 snapshot doesn't start using up space? Shouldn't my ls of the > mountpoint update the atime also? I believe what's happening here is that although we update the in-core atime, we sometimes defer pushing it to disk. You can force the atime to be pushed to disk by unmounting the filesystem. --matt ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] problem with zfs receive -i
On August 19, 2006 7:06:06 PM -0700 Matthew Ahrens <[EMAIL PROTECTED]> wrote: On Sat, Aug 19, 2006 at 06:31:47PM -0700, Frank Cusack wrote: But when I login to zone smb and cd to /share/tmp/.zfs I get 'no such file or directory'. This does exist for other filesystems like /zone/eng/.zfs. My guess is that the filesystem is not mounted. It should be remounted after the 'zfs recv', but perhaps that is not happening correctly. You can see if it's mounted by running 'df' or 'zfs list -o name,mounted'. You are right, it's not mounted. Did the 'zfs recv' print any error messages? nope. Are you able to reproduce this behavior? easily. 1. Is the need to reboot a bug? Certainly having the other snapshots go missing seems like a bug. Yes, it is a bug for the filesystem to not be remounted after the 'zfs recv'. FYI, you should be able to get it mounted again by running 'zfs mount -a', you don't have to reboot the entire zone. yay, that works. 2. Why does the 7.1 snapshot have the extra space? If the filesystem (export/zone/smb/share/tmp) is modified, then some of the data that it shared with the snapshot (@7.1) will not be shared any longer, so it will become unique to the snapshot and show up as "used" space. Even if you didn't explicitly change anything in the filesystem, with the default settings, simply reading files in the filesystem will cause their atimes to be modified. ah ok. Note that if I do zfs send; zfs send -i on the "local side", then do zfs list; zfs mount -a on the "remote side", I still show space used in the @7.1 snapshot, even though I didn't touch anything. I guess mounting accesses the mount point and updates the atime. On the "local" side, how come after I take the 7.1 snapshot and then 'ls', the 7.1 snapshot doesn't start using up space? Shouldn't my ls of the mountpoint update the atime also? -frank ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] problem with zfs receive -i
I followed the formula in zfs(1M) to replicate a zfs filesytem remotely. The initial transfer works as I expected (and as documented). The filesystems were created on the remote side and the data transferred. The man page is really difficult to interpret as to whether the data will be in the filesystem or only in the snapshot, but anyway it did what I wanted. Then I added a file to one of the filesystems and took a second snapshot, and sent it with 'zfs send -i'. No errors from the 'zfs recv' but the data does not appear. There *is* a new snapshot on the remote side, but it's not accessible. Also, the first snapshot is now no longer accessible, in fact all of .zfs is no longer accessible. This is a zoned filesystem. Here you can see they contain the same amount of data: [EMAIL PROTECTED]:~]# zfs list -r export/zone/smb/share/tmp NAME USED AVAIL REFER MOUNTPOINT export/zone/smb/share/tmp48K 225G 25.5K /share/tmp export/zone/smb/share/[EMAIL PROTECTED] 22.5K - 24.5K - export/zone/smb/share/[EMAIL PROTECTED] 0 - 25.5K - [EMAIL PROTECTED]:~]# [EMAIL PROTECTED]:~]# zfs list -r export/zone/smb/share/tmp NAME USED AVAIL REFER MOUNTPOINT export/zone/smb/share/tmp48K 225G 25.5K /share/tmp export/zone/smb/share/[EMAIL PROTECTED] 22.5K - 24.5K - export/zone/smb/share/[EMAIL PROTECTED] 0 - 25.5K - [EMAIL PROTECTED]:~]# But when I login to zone smb and cd to /share/tmp/.zfs I get 'no such file or directory'. This does exist for other filesystems like /zone/eng/.zfs. hmm ok if I reboot the zone .zfs shows up and the filesystem itself (not just the snapshot) contains the new data. Curiously the 7.1 snapshot contains data now. NAME USED AVAIL REFER MOUNTPOINT export/zone/smb/share/tmp 69.5K 225G 25.5K /share/tmp export/zone/smb/share/[EMAIL PROTECTED] 22.5K - 24.5K - export/zone/smb/share/[EMAIL PROTECTED] 21.5K - 25.5K - [EMAIL PROTECTED]:~]# So, questions: 1. Is the need to reboot a bug? Certainly having the other snapshots go missing seems like a bug. 2. Why does the 7.1 snapshot have the extra space? This is S10 06/06 on x86. thanks -frank ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Boot Disk
Tabriz Leman wrote: Torrey McMahon wrote: Lori Alt wrote: No, zfs boot will be supported on both x86 and sparc. Sparc's OBP, and various x86 BIOS's both have restrictions on the devices that can be accessed at boot time, so we need to limit the devices in a root pool on both architectures. Hi Lori. Can you expand a bit on the above? What sort of limitations are you referring too? (Boot time? Topology?) I think what Lori is referring to here is that we need to limit the rootpool to BIOS/OBP visible devices; not all devices are visible from the BIOS/OBP (fibre channel devices, for example). Actually, OBP and BIOS should have access to fabric devices. I know OBP does and I've seen docs that mention BIOS does. (Look in the x86 fabric boot docs for example) I think the problem is more around, as Lori mentioned in her email, the ability to traverse a ZFS pool when the ZFS drivers haven't been loaded. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] SPEC SFS97 benchmark of ZFS,UFS,VxFS
On August 19, 2006 10:53:55 AM -0700 Eric Redmond <[EMAIL PROTECTED]> wrote: Sun Cluster 3.2: New Features wow, this makes 3.1 sound like dog food. -frank ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] SPEC SFS97 benchmark of ZFS,UFS,VxFS
George Wilson wrote On 08/18/06 14:08,:
Frank,
The SC 3.2 beta maybe closed but I'm forwarding your request to Eric
Redmond.
The Sun Cluster 3.2 Beta program has been extended. You can apply for
the Beta via this URL:
https://feedbackprograms.sun.com/callout/default.html?callid={11B4E37C-D608-433B-AF69-07F6CD714AA1}
Sun Cluster 3.2: New Features
Ease of Use
New Sun Cluster Object Oriented Command Set
The
new SC command line interface includes one command per cluster object
type and consistent use of sub-command names and option letters. It
also supports short and long command names. The commands output have
been greatly improved with better help and error messages as well as
more readable status and configuration reporting. In addition some
commands include export and import options with use of portable
XML-based configuration files allowing replication of portion of, or
entire cluster configurations.
This
new interface is easier to learn and easier to use, thereby limiting
human errors during administration of clusters. It also speeds up
partial or full configuration cloning.
Oracle RAC 10g improved integration and administration
Sun
Cluster RAC packages installation as well as configuration are now
integrated in the Sun Cluster procedures. New RAC specific resource
types and properties can be used for finer grained control.
Oracle
RAC extended manageability leads to easier set-up of Oracle RAC within
Sun Cluster as well as improved diagnosability and availability.
Agent configuration wizards
New
GUI-based wizard provides simplified configuration for popular
applications via on-line help, automatic discovery of parameter choices
and immediate validation. Supported applications include Oracle RAC and
HA, NFS, Apache and SAP.
The configuration of agents is easier and less error-prone
enabling faster set-up of popular solutions.
Flexible IP address scheme
Sun
Cluster now allows a reduced range of IP addresses for its private
interconnect. In addition it becomes also possible to customize the IP
base address and its range during or after installation.
These changes facilitate integration of Sun Cluster
environments in existing networks with limited or regulated address
spaces.
Availability
Cluster support for SMF services
Sun
Cluster now integrates tightly with Solaris 10 Service Management
Facility (SMF) and enables the encapsulation of SMF controlled
applications in the Sun Cluster resource management model. Local
service-level life-cycle management continues to be operated by SMF
while whole resource level cluster-wide failure (node, storage, ...)
handling operations are carried out by Sun Cluster.
Moving
applications from a single node Solaris 10 environment to multi-node
Sun Cluster environment enables increased availability while requiring
limited-to-no effort.
Extended flexibility for fencing protocol
This new functionality allows the customization of the
default fencing protocol: choices include
SCSI 3, SCSI 2 or per-device discovery.
This
flexibility enables the default usage of SCSI 3, a more recent
protocol, for better support for multi-pathing, easier integration with
non-Sun storage and shorter recovery times on newer storage while still
supporting the SC 3.0/3.1 behavior and SCSI 2 for older devices.
Quorum Server
A
new quorum device option is now available in Sun Cluster: instead of
using a shared disk and SCSI reservation protocols, it is now possible
to use a Solaris server outside of the cluster to run a quorum server
module supporting an atomic reservation protocol over TCP/IP.
This
enables faster failover time but also lowers deployment costs: it
removes the need of a shared quorum disk for any scenario where quorum
is required (2-node) or desired.
Disk path failure handling
Sun Cluster can now be configured to automatically reboot a
node if all its path to shared disk have failed.
Faster reaction in case of severe disk path failure enables
improved availability.
HA Storage plus availability improvements
HA
Storage plus mount points are created automatically in case of mount
failure to eliminate failure-to-failover cases thus improving
availability of the environment
Flexibility
Solaris Container expanded support
Any
application of scalable or failover type and their associated Sun
Cluster agents can now run unmodified within Solaris Containers (except
Oracle RAC).
This
allows the combination of the benefits of application containment
offered by Solaris containers and the increased availability provided
by Sun Cluster.
Note: Currently only the following Sun Cluster Agents are supported in
Solaris Containers
JES Application
Server
JES Web Server
JES MQ Server
DNS
Apache
Kerberos
HA-Oracle
HA ZFS
ZFS is supported as a failover file system in Sun Cluster.
ZFS
and Sun Cluster offers a best class file system solution combining high
availability, data integrity, performance and scalability covering the
needs of the most demanding environments.
H
Re: [zfs-discuss] in-kernel gzip compression
On Sat, Aug 19, 2006 at 01:25:21PM +0200, michael schuster wrote: > maybe a stupid question: what do we use for compressing dump data on the > dump device? We use a variant of Lempel-Ziv called lzjb (the jb is for Jeff Bonwick). The algorithm was designed for very small code/memory footprint and to be very fast (single CPU can compress data at 150MB/s). When running a compression algorithm in panic context, you have a lot of constraints. --Bill ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] in-kernel gzip compression
Matthew Ahrens wrote: On Thu, Aug 17, 2006 at 02:53:09PM +0200, Robert Milkowski wrote: Hello zfs-discuss, Is someone actually working on it? Or any other algorithms? Any dates? Not that I know of. Any volunteers? :-) (Actually, I think that a RLE compression algorithm for metadata is a higher priority, but if someone from the community wants to step up, we won't turn your code away!) maybe a stupid question: what do we use for compressing dump data on the dump device? Michael ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
