Re: [zfs-discuss] system unresponsive after issuing a zpool attach
I believe this is what you're hitting: 6456888 zpool attach leads to memory exhaustion and system hang We are currently looking at fixing this so stay tuned. Thanks, George Daniel Rock wrote: Joseph Mocker schrieb: Today I attempted to upgrade to S10_U2 and migrate some mirrored UFS SVM partitions to ZFS. I used Live Upgrade to migrate from U1 to U2 and that went without a hitch on my SunBlade 2000. And the initial conversion of one side of the UFS mirrors to a ZFS pool and subsequent data migration went fine. However, when I attempted to attach the second side mirrors as a mirror of the ZFS pool, all hell broke loose. 9. attach the partition to the pool as a mirror zpool attach storage cXtXdXs4 cYtYdYs4 A few minutes after issuing the command the system became unresponsive as described above. Same here. I also did upgrade to S10_U2, and converted my non-root md similar like you. Everything went fine until the zpool attach. The system seemed to be hanging for at least 2-3 minutes. Then I could type something again. top then showed 98% system time. This was on a SunBlade 1000 with 2 x 750MHz CPUs. The zpool/zfs was created with checksum=sha256. Daniel ___ 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[2]: [zfs-discuss] zpool import - cannot mount [...] directory is not empty
Hello Eric, Wednesday, August 16, 2006, 4:48:46 PM, you wrote: ES What does 'zfs list -o name,mountpoint' and 'zfs mount' show after the ES import? My only guess is that you have some explicit mountpoint set ES that's confusing the DSl-orderered mounting code. If this is the case, ES this was fixed in build 46 (likely to be in S10u4) to always mount ES datasets in mountpoint order, regardless of their hierarchical ES relationship. However, you may be hitting some other bug that we ES haven't seen before. bash-3.00# zfs list -o name,mountpoint NAME MOUNTPOINT nfs-s5-p0 /nfs-s5-p0 nfs-s5-p0/d5110 /nfs-s5-p0/d5110 nfs-s5-p0/d5111 /nfs-s5-p0/d5111 nfs-s5-p0/d5112 /nfs-s5-p0/d5112 nfs-s5-p0/d5113 /nfs-s5-p0/d5113 nfs-s5-p0/d5114 /nfs-s5-p0/d5114 nfs-s5-p0/d5115 /nfs-s5-p0/d5115 nfs-s5-p0/d5116 /nfs-s5-p0/d5116 nfs-s5-p1 /nfs-s5-p1 nfs-s5-p1/d5117 /nfs-s5-p1/d5117 nfs-s5-p1/d5118 /nfs-s5-p1/d5118 nfs-s5-p1/d5119 /nfs-s5-p1/d5119 nfs-s5-p1/d5120 /nfs-s5-p1/d5120 nfs-s5-p1/d5121 /nfs-s5-p1/d5121 nfs-s5-p1/d5122 /nfs-s5-p1/d5122 nfs-s5-p1/d5123 /nfs-s5-p1/d5123 nfs-s5-p2 /nfs-s5-p2 nfs-s5-p2/d5124 /nfs-s5-p2/d5124 nfs-s5-p2/d5125 /nfs-s5-p2/d5125 nfs-s5-p2/d5126 /nfs-s5-p2/d5126 nfs-s5-p2/d5127 /nfs-s5-p2/d5127 nfs-s5-p2/d5128 /nfs-s5-p2/d5128 nfs-s5-p2/d5129 /nfs-s5-p2/d5129 nfs-s5-p2/d5130 /nfs-s5-p2/d5130 nfs-s5-p3 /nfs-s5-p3 nfs-s5-p3/d5131 /nfs-s5-p3/d5131 nfs-s5-p3/d5132 /nfs-s5-p3/d5132 nfs-s5-p3/d5133 /nfs-s5-p3/d5133 nfs-s5-p3/d5134 /nfs-s5-p3/d5134 nfs-s5-p3/d5135 /nfs-s5-p3/d5135 nfs-s5-p3/d5136 /nfs-s5-p3/d5136 nfs-s5-p3/d5137 /nfs-s5-p3/d5137 bash-3.00# -- 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
Re: [zfs-discuss] Re: system unresponsive after issuing a zpool attach
And it started replacement/resilvering... after few minutes system became unavailbale. Reboot only gives me a few minutes, then resilvering make system unresponsible. Is there any workaroud or patch for this problem??? Argh, sorry -- the problem is that we don't do aggressive enough scrub/resilver throttling. The effect is most pronounced on 32-bit or low-memory systems. We're working on it. One thing you might try is reducing txg_time to 1 second (the default is 5 seconds) by saying this: echo txg_time/W1 | mdb -kw. Let me describe what's happening, and why this may help. When we kick off a scrub (same code path as resilver, so I'll use the term generically), we traverse the entire block tree looking for blocks that need scrubbing. The tree traversal itself is single-threaded, but the work it generates is not -- each time we find a block that needs scrubbing, we schedule an async I/O to do it. As you've discovered, we can generate work faster than the I/O subsystem can process it. To avoid overloading the disks, we throttle I/O downstream, but we don't (yet) have an upstream throttle. If we discover blocks really fast, we can end up scheduling lots of I/O -- and sitting on lots of memory -- before the downstream throttle kicks in. The reason this relates to txg_time is that every time we sync a transaction group, we suspend the scrub thread and wait for all pending scrub I/Os to complete. This ensures that we won't asynchronously scrub a block that was freed and reallocated in a future txg; when coupled with the COW nature of ZFS, this allows us to run scrubs entirely independent of all filesystem-level structure (e.g. directories) and locking rules. This little trick makes the scrubbing algorithms *much* simpler. The key point is that each spa_sync() throttles the scrub to zero. By lowering txg_time from 5 to 1, you're cutting down the maximum number of pending scrub I/Os by roughly 5x. The unresponsiveness you're seeing is a threshold effect; I'm hoping that by running spa_sync() more often, we can get you below that threshold. Please let me know if this works for you. Jeff ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS se6920
WYT said: Hi all, My company will be acquiring the Sun SE6920 for our storage virtualization project and we intend to use quite a bit of ZFS as well. The 2 technologies seems somewhat at odds since the 6920 means layers of hardware abstraction but ZFS seems to prefer more direct access to disk. I tried to search around but couldn't find any performance numbers of ZFS on SE6920 nor any recommendations where to start or what the considerations could be. Will appreciate any hints in this area. Thanks. -- Just me, Wire ... ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss My general principles are: If you can, to improve you 'Availability' metrics, let ZFS handle one level of redundancy; For Random Read performance prefer mirrors over raid-z. If you use raid-z, group together a smallish number of volumes. setup volumes that correspond to small number of drives (smallest you can bear) with a volume interlace that is in the [1M-4M] range. And next, a very very important thing that we will have to pursue with Storage Manufacturers including ourself: In cases where the storage cache is to be considered stable storage in the face of power failure, we have to be able to configure the storage to ignore the flush write cache commands that ZFS issues. Some Storage do ignore the flush out of the box, others don't. It should be easy to verify the latency of a small O_DSYNC write. On a quiet system, I expect sub millisec response. 5ms to a battery protected cache should be red-flagged. This was just filed to track the issue: 6460889 zil shouldn't send write-cache-flush command to some devices Note also that S10U2 has already been greatly improved performance wise, tracking releases is very important. -r Performance, Availability Architecture Engineering Roch BourbonnaisSun Microsystems, Icnc-Grenoble Senior Performance Analyst 180, Avenue De L'Europe, 38330, Montbonnot Saint Martin, France http://icncweb.france/~rbourbon http://blogs.sun.com/roller/page/roch [EMAIL PROTECTED] (+33).4.76.18.83.20 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] zpool status inconsistent after user error?
Hi, IHAC who is simulating disk failure and came across behaviour which seems wrong: 1. zpool status -v pool: data state: ONLINE scrub: resilver completed with 0 errors on Thu Aug 10 16:55:22 2006 config: NAMESTATE READ WRITE CKSUM dataONLINE 0 0 0 mirrorONLINE 0 0 0 c1t2d0 ONLINE 0 0 0 c1t3d0 ONLINE 0 0 0 2. zpool offline data c1t3d0 zpool status -v: NAMESTATE READ WRITE CKSUM dataDEGRADED 0 0 0 mirrorDEGRADED 0 0 0 c1t2d0 ONLINE 0 0 0 c1t3d0 OFFLINE 0 0 0 !! this because the following cfgadm -c unconfigure would refuse to work !! otherwise. Cust will retest with cfgadm -f .. 3. cfgadm -c unconfigure c1::dsk/c1t3d0 4. zpool online data c1t3d0 zpool status -v: NAMESTATE READ WRITE CKSUM dataDEGRADED 0 0 0 mirrorDEGRADED 0 0 0 c1t2d0 ONLINE 0 0 0 c1t3d0 UNAVAIL 0 0 0 cannot open 5. cfgadm -c configure c1::dsk/c1t3d0 6. zpool status -v pool: data state: ONLINE scrub: resilver completed with 0 errors on Thu Aug 10 17:04:42 2006 config: NAMESTATE READ WRITE CKSUM dataONLINE 0 0 0 mirrorONLINE 0 0 0 c1t2d0 ONLINE 0 0 0 c1t3d0 ONLINE 0 0 0 errors: No known data errors !! note: c1t3d0 is shown online; also note the resilver timestamp - it has !! changed from the first status -v output. !! but when cust now tries to offline the other mirror half, he !! gets an error: 7. zpool offline data c1t2d0 cannot offline c1t2d0: no valid replicas !! cust is aware that the order of commands may not be orthodox, but !! still is worried that although zpool status says 'everything online', !! he cannot offline the other mirror half. Comments? Suggestions? RTFMs? TIA Michael -- Michael Schuster (+49 89) 46008-2974 / x62974 visit the online support center: http://www.sun.com/osc/ Recursion, n.: see 'Recursion' ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: ZFS write performance problem with compression set to ON
Therein lies my dillemma: - We know the I/O sub-system is capable of much higher I/O rates - Under the test setup I've SAS datasets which are lending themselves to compression. This should manifest itself as lots of read I/O resulting in much smaller (4x) write I/O due to compression. This means my read rates should be driven higher to keep the compression. I don't see this, as I said in my original post I see reads comes in waves. I'm beginning to think my write rates are hitting a a bottleneck in compression as follows: - ZFS issues reads - ZFS starts compressing the data before the write and cannot drain the input buffers fast enough; this results in reads to stop. - ZFS completes compression and writes out data at a much smaller rate due to the smaller compressed data stream. I'm not a filesystem wizard but shouldn't ZFS take advantage of my available CPUs to drain the input buffer faster (parallel)? It is possible that you've some internal throttles in place to make ZFS a good citizen in the Solaris landscape; a la algorithms in place to prevent cache flooding by one host/device in EMC/Hitachi. I'll perform some more tests with different datasets and report to the forum. Now if only I can convince my storage administrator to provision me raw disks instead of the mirrored disks so I can let ZFS do the same for me, another battle another day ;-) Thanks. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: ZFS write performance problem with compression set to ON
Anantha N. Srirama writes: Therein lies my dillemma: - We know the I/O sub-system is capable of much higher I/O rates - Under the test setup I've SAS datasets which are lending themselves to compression. This should manifest itself as lots of read I/O resulting in much smaller (4x) write I/O due to compression. This means my read rates should be driven higher to keep the compression. I don't see this, as I said in my original post I see reads comes in waves. I'm beginning to think my write rates are hitting a a bottleneck in compression as follows: - ZFS issues reads - ZFS starts compressing the data before the write and cannot drain the input buffers fast enough; this results in reads to stop. - ZFS completes compression and writes out data at a much smaller rate due to the smaller compressed data stream. I'm not a filesystem wizard but shouldn't ZFS take advantage of my available CPUs to drain the input buffer faster (parallel)? It is possible that you've some internal throttles in place to make ZFS a good citizen in the Solaris landscape; a la algorithms in place to prevent cache flooding by one host/device in EMC/Hitachi. I'll perform some more tests with different datasets and report to the forum. Now if only I can convince my storage administrator to provision me raw disks instead of the mirrored disks so I can let ZFS do the same for me, another battle another day ;-) Thanks. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss Yes, compression runs in the context of a single thread per pool so it seems quite possible that it will cause the behavior you see. The issue is being tracked here: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6460622 -r ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re[2]: [zfs-discuss] zpool import/export
Hello Eric, Wednesday, August 16, 2006, 4:49:27 PM, you wrote: ES This seems like a reasonable RFE. Feel free to file it at ES bugs.opensolaris.org. I've just did :) However currently 'zpool import A B' means importing pool A and renaming it to pool B. I think it would be better to change current behavior and rename only with given switch like 'zpool import A -n B' or something like that and 'zpool import A B' (zpool import pool ... ...) means importing all those specified pools. That way it will be more intuitive and consistent with zpool export. What do you think? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re[2]: [zfs-discuss] ZFS se6920
Hello Roch, Thursday, August 17, 2006, 11:08:37 AM, you wrote: R My general principles are: R If you can, to improve you 'Availability' metrics, R let ZFS handle one level of redundancy; R For Random Read performance prefer mirrors over R raid-z. If you use raid-z, group together a smallish R number of volumes. R setup volumes that correspond to small number of R drives (smallest you can bear) with a volume R interlace that is in the [1M-4M] range. Why that big interlace? With lot of small reads it could actually introduce large overhead, right? I can understand something like 960KB, but 4M? -- 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] in-kernel gzip compression
Hello zfs-discuss, Is someone actually working on it? Or any other algorithms? Any dates? -- Best regards, Robert mailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: commercial backup software and zfs
Hi there Did a backup/restore on TSM, works fine. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: Re[2]: [zfs-discuss] ZFS se6920
Robert Milkowski writes: Hello Roch, Thursday, August 17, 2006, 11:08:37 AM, you wrote: R My general principles are: R If you can, to improve you 'Availability' metrics, R let ZFS handle one level of redundancy; R For Random Read performance prefer mirrors over R raid-z. If you use raid-z, group together a smallish R number of volumes. R setup volumes that correspond to small number of R drives (smallest you can bear) with a volume R interlace that is in the [1M-4M] range. Why that big interlace? With lot of small reads it could actually introduce large overhead, right? I can understand something like 960KB, but 4M? I also think we should be fine with 1M. Not sure what overhead we're talking here. Did you mean large skew ? During a pool synch, at least, one of interest, we expect to have lots of data to synch, even if it's just a 1GB, 4M interlace still spreads to 256 disks. -r ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Why is ZFS raidz slower than simple ufs mount?
Hi Bob, you are using some non-Sun SCSI HBA. Could you please be more specific about HBA model and driver? You are getting pretty the same high CPU load with write to single-disk UFS and raid-z. This may mean that the problem is not with ZFS itself. Victor Bob Evans wrote: Robert, Sorry about not being clearer. The storage unit I am using is configured as follows: X X X X X X X X X X X X X X \ \-- (Each X is an 18 GB SCSI Disk) The first 7 disks have been used for the ZFS RaidZ, I used the last disk (#14) for my UFS target. The first 7 are on one scsi channel, the next 7 are on the other channel. Here is the output of zpool status: pool: z state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM z ONLINE 0 0 0 raidz ONLINE 0 0 0 c3t0d0 ONLINE 0 0 0 c3t1d0 ONLINE 0 0 0 c3t2d0 ONLINE 0 0 0 c3t3d0 ONLINE 0 0 0 c3t4d0 ONLINE 0 0 0 c3t5d0 ONLINE 0 0 0 c3t8d0 ONLINE 0 0 0 errors: No known data errors Here is the format of each of the 14 disks in the array: partition print Current partition table (original): Total disk sectors available: 35548662 + 16384 (reserved sectors) Part TagFlag First SectorSizeLast Sector 0usrwm34 16.95GB 35548662 1 unassignedwm 0 0 0 2 unassignedwm 0 0 0 3 unassignedwm 0 0 0 4 unassignedwm 0 0 0 5 unassignedwm 0 0 0 6 unassignedwm 0 0 0 8 reservedwm 35548663 8.00MB 35565046 I ufs mounted the target disk by doing the following: newfs /dev/rdsk/c4t8d0s0 mount /foo /dev/dsk/c4t8d0s0 Thanks! This message posted from opensolaris.org ___ 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] Re: commercial backup software and zfs
No ACL's ... 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: Why is ZFS raidz slower than simple ufs mount?
First, I apologize, I listed the Antares in my original post, it was one of two scsi cards I tested with. The posted CPU snapshots were from the LSI 22320 card (mentioned below). I've tried this with two different SCSI cards. As far as I know, both are standard SCSI cards used for Suns. Sun lists the LSI 22320 as a supported HBA (I believe). They are: LSI 22320 64-bit PCI-X Ultra 320 SCSI Dual Channel HBA (newer card) Antares PCI SCSI-2U2WL dual 80 MB/Sec SCSI (older card) I get the same results for both cards... I use the default drivers that Solaris 10 Update 2 provides. I think we got the newer card through Sun, but I don't have the original box. The older card had been used in an Enterprise 450 box. Bob 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] in-kernel gzip compression
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!) --matt ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] in-kernel gzip compression
On Thu, Aug 17, 2006 at 10:00:32AM -0700, Matthew Ahrens wrote: (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!) Is RLE likely to be more efficient for metadata? Have you taking a stab as estimating the comparative benefits? Adam -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] in-kernel gzip compression
On Thu, Aug 17, 2006 at 10:28:10AM -0700, Adam Leventhal wrote: On Thu, Aug 17, 2006 at 10:00:32AM -0700, Matthew Ahrens wrote: (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!) Is RLE likely to be more efficient for metadata? No, it it not likely to achieve a higher compression ratio. However, it should use significantly less CPU time. We've seen some circumstances where the CPU usage caused by compressing metadata can be not as trivial as we'd like. --matt ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Why is ZFS raidz slower than simple ufs mount?
Bob Evans wrote: Hi, this is a follow up to Significant pauses to zfs writes. I'm getting about 15% slower performance using ZFS raidz than if I just mount the same type of drive using ufs. What is your expectation? -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Proposal: user-defined properties
Following up on a string of related proposals, here is another draft
proposal for user-defined properties. As usual, all feedback and
comments are welcome.
The prototype is finished, and I would expect the code to be integrated
sometime within the next month.
- Eric
INTRODUCTION
ZFS currently supports a well-defined set of properties for managing ZFS
datasets. These properties represent either read-only statistics
exported by the ZFS framework ('available', 'compressratio', etc), or
editable properties which affect the behavior of ZFS ('compression',
'readonly', etc).
While these properties provide a structured way to interact with ZFS, a
common request is to allow unstructured properties to be attached to ZFS
datasets. This is covered by the following RFE:
6281585 user defined properties
This would allow administrators to add annotations to datasets, as well
as allowing ISVs to store application-specific settings that interact
with individual datasets.
DETAILS
This proposal adds a new classification of ZFS properties known as 'user
properties'. The existing native properties will remain, as they
provide additional semantics (mainly validation) which are closely tied
to the underlying implementation.
Any property which contains a colon (':') is defined as a 'user
property'. The name can contain alphanumeric characters, plus the
following special characters: ':', '-', '.', '_'. User properties are
always strings, and are always inherited. No additional validation is
done on the contents. Properties are set and retrieved through the
standard mechanisms: 'zfs set', 'zfs get', and 'zfs inherit'.
Inheriting a property which is not set in any parent is equivalent to
clearing the property, as there is no default value for user-defined
properties.
It is expected that the colon will serve two purposes: to distinguish
between native properties and provide an (unenforced) namespace for user
properties. For example, it is hoped that properties are defined as
'module:property', to group properties together and to provide a
larger namespace for logical separation of properties. No enforcement
of this namespace is done by ZFS, however, and the empty string is valid
on both sides of the colon.
EXAMPLES
# zfs set local:department=12345 test
# zfs get -r local:department test
NAME PROPERTY VALUE SOURCE
test local:department 12345 local
test/foo local:department 12345 inherited from test
# zfs list -o name,local:department
NAME LOCAL:DEPARTMENT
test 12345
test/foo 12345
# zfs set local:department=67890 test/foo
# zfs inherit local:department test
# zfs get -s local -r all test
NAME PROPERTY VALUE SOURCE
test/foo local:department 12345 local
# zfs list -o name,local:department
NAME LOCAL:DEPARTMENT
test -
test/foo 12345
MANPAGE CHANGES
TBD
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] commercial backup software and zfs
On 8/15/06, Kevin Maguire [EMAIL PROTECTED] wrote: Hi Is the following an accurate sstatment of the current status with (for me) the 3 main commercial ackup software solutions out there It seems to me that if zfs send/receive where hooked in with ndmp (http://ndmp.org), that zfs would very quickly have pretty broad backup support. This could provide a distributed, authenticated transport for replicating file systems using ndmpcopy or some of the snap* enhancements to ndmp offered up by Netapp. But then again, I haven't followed the world of NDMP lately, and the efforts at turning the various NDMP Internet drafts into RFC's seems to be stalled. A quick search of existing Open Source NDMP implementations doesn't turn up much. Do others on the list have more insight into whether this has been considered? Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
