Re: [zfs-discuss] zfs diff performance
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Ulrich Graef > > Do you use de-duplication? (does not directly harm the performance, but > needs memory > and slows down zfs diff through that)? Yikes. That couldn't be more wrong. Yes, dedup hurts performance, badly. Yes, in theory dedup should be able to accelerate performance, but the way it's presently implemented, it gets hurt too dramatically by hard disk seek/latency access time. The way it's presently implemented, there is one and only one way dedup improves performance, which is when you read duplicate blocks, then you get about 2-4x read performance gain. For all other operations - write duplicate, read nonduplicate, write nonduplicate... Performance is worse with dedup. As little as 2x, as high as 10x or 20x if you have sufficient memory *and* you optimize (because the out-of-the-box configuration is very nearly unusable), and infinite-x if you're having insufficient memory or you fail to optimize. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs diff performance
On 02/28/12 12:53 PM, Ulrich Graef wrote: Hi Ian, On 26.02.12 23:42, Ian Collins wrote: I had high hopes of significant performance gains using zfs diff in Solaris 11 compared to my home-brew stat based version in Solaris 10. However the results I have seen so far have been disappointing. Testing on a reasonably sized filesystem (4TB), a diff that listed 41k changes took 77 minutes. I haven't tried my old tool, but I would expect the same diff to take a couple of hours. Size does not matter (at least here). How many files do you have and do you have enough cache in main memory (25% of ARC) or cache device (set to metadata only). Last time I looked, about 10 million files. If you are able to manage that every dnode (512 Byte) is in the ARC or the L2ARC then your compare will fly! When your are doing too much other stuff (do you IO? Do you have applications running?) They will move dnode data out of the direct access and compare needs to read a lot from disk. There was a send running form the same pool. You are comparing a measurement with a guess. That is not a valid test. The guess is based on the last time I ram my old diff tool. The box is well specified, an x4270 with 96G of RAM and a FLASH accelerator card used for log and cache. Number of files/size of files is missing. As I said, about 10 million, various sized form bytes to Gbytes. How much of the pool is used (in %)? 63% Perhaps the recordsize is lowered, then How much is used for the cache. Did you set secondarycache=metadata? No. When, is your burn in long enough, that all the metadata is on fast devices? How large is your L2ARC? 72GB. What is running in parallel to your test? What is the disk configuration (you know: disks are slow)? stripe of 5 2 way mirrors. Do you use de-duplication (does not directly harm the performance, but needs memory and slows down zfs diff through that)? No dedup! Tell me the hit rates of the cache (metadata and data in ARC and L2ARC). Good? I'll have to check next time I run a diff. Raidz or mirror? Are there any ways to improve diff performance? Yes. Mainly memory. Or use less files. Tell that to the users! -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs diff performance
Hi Ian, On 26.02.12 23:42, Ian Collins wrote: I had high hopes of significant performance gains using zfs diff in Solaris 11 compared to my home-brew stat based version in Solaris 10. However the results I have seen so far have been disappointing. Testing on a reasonably sized filesystem (4TB), a diff that listed 41k changes took 77 minutes. I haven't tried my old tool, but I would expect the same diff to take a couple of hours. Size does not matter (at least here). How many files do you have and do you have enough cache in main memory (25% of ARC) or cache device (set to metadata only). If you are able to manage that every dnode (512 Byte) is in the ARC or the L2ARC then your compare will fly! When your are doing too much other stuff (do you IO? Do you have applications running?) They will move dnode data out of the direct access and compare needs to read a lot from disk. You are comparing a measurement with a guess. That is not a valid test. The box is well specified, an x4270 with 96G of RAM and a FLASH accelerator card used for log and cache. Number of files/size of files is missing. How much of the pool is used (in %)? Perhaps the recordsize is lowered, then How much is used for the cache. Did you set secondarycache=metadata? When, is your burn in long enough, that all the metadata is on fast devices? How large is your L2ARC? What is running in parallel to your test? What is the disk configuration (you know: disks are slow)? Do you use de-duplication (does not directly harm the performance, but needs memory and slows down zfs diff through that)? Tell me the hit rates of the cache (metadata and data in ARC and L2ARC). Good? Raidz or mirror? Are there any ways to improve diff performance? Yes. Mainly memory. Or use less files. Regards, Ulrich -- Ulrich Graef / Principal Sales Consultant / Phone: + 49 6103 752 359 ORACLE Deutschland B.V.& Co. KG / Amperestr. 6 / 63225 Langen http://www.oracle.com ORACLE Deutschland B.V.& Co. KG Hauptverwaltung: Riesstr. 25, D-80992 Muenchen Registergericht: Amtsgericht Muenchen, HRA 95603 Geschaeftsfhrer: Juergen Kunz Komplementaerin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschaeftsfhrer: Alexander van der Ven, Astrid Kepper, Val Maher ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] zfs diff performance
I had high hopes of significant performance gains using zfs diff in Solaris 11 compared to my home-brew stat based version in Solaris 10. However the results I have seen so far have been disappointing. Testing on a reasonably sized filesystem (4TB), a diff that listed 41k changes took 77 minutes. I haven't tried my old tool, but I would expect the same diff to take a couple of hours. The box is well specified, an x4270 with 96G of RAM and a FLASH accelerator card used for log and cache. Are there any ways to improve diff performance? -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] "zfs diff" performance disappointing
On 09/27/11 10:59 AM, Tomas Forsman wrote: On 27 September, 2011 - Ian Collins sent me these 0,8K bytes: On 09/27/11 07:55 AM, Jesus Cea wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just upgraded to Solaris 10 Update 10, and one of the improvements is "zfs diff". Using the "birthtime" of the sectors, I would expect very high performance. The actual performance doesn't seems better that an standard "rdiff", though. Quite disappointing... Should I disable "atime" to improve "zfs diff" performance? (most data doesn't change, but "atime" of most files would change). I tend to disable atime in the root filesystem and only enable it on a filesystem if required. So far, it has never been required on any of the systems I look after! I've found it useful time after time.. do things and then check atime to see whatever files it looked at.. (yes, I know about truss and dtrace) It can be useful, but unless you really want the functionality, it generates a lot of unnecessary writes. -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] "zfs diff" performance disappointing
On 27 September, 2011 - Ian Collins sent me these 0,8K bytes:
> On 09/27/11 07:55 AM, Jesus Cea wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> I just upgraded to Solaris 10 Update 10, and one of the improvements
>> is "zfs diff".
>>
>> Using the "birthtime" of the sectors, I would expect very high
>> performance. The actual performance doesn't seems better that an
>> standard "rdiff", though. Quite disappointing...
>>
>> Should I disable "atime" to improve "zfs diff" performance? (most data
>> doesn't change, but "atime" of most files would change).
>>
> I tend to disable atime in the root filesystem and only enable it on a
> filesystem if required. So far, it has never been required on any of
> the systems I look after!
I've found it useful time after time.. do things and then check atime
to see whatever files it looked at..
(yes, I know about truss and dtrace)
/Tomas
--
Tomas Forsman, st...@acc.umu.se, http://www.acc.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,acc}.umu.se
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] "zfs diff" performance disappointing
On 09/27/11 07:55 AM, Jesus Cea wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just upgraded to Solaris 10 Update 10, and one of the improvements is "zfs diff". Using the "birthtime" of the sectors, I would expect very high performance. The actual performance doesn't seems better that an standard "rdiff", though. Quite disappointing... Should I disable "atime" to improve "zfs diff" performance? (most data doesn't change, but "atime" of most files would change). I tend to disable atime in the root filesystem and only enable it on a filesystem if required. So far, it has never been required on any of the systems I look after! -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] "zfs diff" performance disappointing
Ah yes, of course. I'd misread your original post. Yes, disabling atime updates will reduce the number of superfluous transactions. It's *all* transactions that count, not just the ones the app explicitly caused, and atime implies lots of transactions. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] "zfs diff" performance disappointing
On 09/26/11 12:31, Nico Williams wrote: > On Mon, Sep 26, 2011 at 1:55 PM, Jesus Cea wrote: >> Should I disable "atime" to improve "zfs diff" performance? (most data >> doesn't change, but "atime" of most files would change). > > atime has nothing to do with it. based on my experiences with time-based snapshots and atime on a server which had cron-driven file tree walks running every night, I can easily believe atime has a lot to do with it - the atime updates associated with a tree walk will mean that that much of a filesystem's metadata will diverge between the writeable filesystem and its last snapshot. - Bill ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] "zfs diff" performance disappointing
On Mon, 26 Sep 2011, Jesus Cea wrote: "rsync" takes a bit less than 7 minutes. So "zfs diff" is actually slower!. It is important to define what is meant by "rsync". For example, a common rsync operating mode is to simply compare whole-file timestamps and file size in order to determine that a file has changed. However, zfs surely works at the zfs block level so it does more work due to files being comprised of multiple blocks. Rsync may be executed in a mode (--checksum) by which it compares blocks of data. This mode would be considerably slower. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] "zfs diff" performance disappointing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/09/11 22:54, Jesus Cea wrote: > On 26/09/11 22:29, David Magda wrote: >> Talking about "7.55 GB" is mostly useless as well. If it's a >> dozen video files then stat()ing them all with be done very >> quickly by just running find(1). If however the 7.55 GB is made >> up of 7,550,000 files then going through them would take quite a >> long time. > > Point taken, although "zfs diff" time is (should) proportional to > changes, not to number of files. Providing info, the "used" column in "zfs list" for these snapshots, giving the "difference" between adjacent snapshots, is around 30MB (with "atime" active). 10 minutes to dig in 30MB... - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBToDnrJlgi5GaxT1NAQJKFwP/XqkUeEi66WynywY4BpWishHwmEtMfZIv Ex5YG38/5k+0lmuMDX3wGKxTueA08AxV5YOSyFJ23Rf3FCqksJ7C8ZX2PFIT3I2D 4Z52QKMF6tw9OzcCavkLE+15pp1IEixutcLnS8mVv7gw1SHrmGyIQvXpouL3sM4a dbKdHyUVHQk= =sD8O -END PGP SIGNATURE- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] "zfs diff" performance disappointing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/09/11 21:31, Nico Williams wrote: > atime has nothing to do with it. > > How much work zfs diff has to do depends on how much has changed > between snapshots. That is what I thought, but look at my example: less than 20 changes and more than 10 minutes to locate them... Technically, if a datasets have "atime" active, the FS diverges from the "dataset" even if the "data" is not changed. I just did a snapshot over another unchanged snapshot. "zfs diff" finish inmediatelly with no changes, and it should be. But doing a "zfs diff" of "/usr/local/" takes a lot of time, even without changes. I am really thinking that "atime" is actually playing a role. In my personal situation, I am doing "zfs diff" between snapshots taken on the receive side of an "rdiff --inplace". I would say that "rdiff" is modifying the "atime" of ALL files in the receiving "dataset", and although that is not showed in "zfs diff", it is "breaking" the tree pruning by "birthdate" age. I just disabled "atime" in this particular dataset. I do a new "rdiff - --inplace" on it (as the destination). After that, "zfs diff" takes 12 seconds instead of the initial 10 minutes. A big improvement. So, yes, "atime" seems to be harmful. Badly. PS: I saw something similar with "zfs send" too. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBToDml5lgi5GaxT1NAQIWQgQAnoeFnltM1SyzUWDb5fxxYQJIff19B8Gp 5jpfHw3dcri6OYQzUkqxCAq0QvQdzMP899HPE2gx8yW1XqC706H1xaVsM1Ho7IJM ZzKPulCAoEZ7njYo2ycipDIlQtxdaSuA9UPu6XDY142fq5GmnMx9lCChuWLK5gDb Ox+ffh4867k= =Ji6T -END PGP SIGNATURE- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] "zfs diff" performance disappointing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/09/11 22:29, David Magda wrote: > Talking about "7.55 GB" is mostly useless as well. If it's a dozen > video files then stat()ing them all with be done very quickly by > just running find(1). If however the 7.55 GB is made up of > 7,550,000 files then going through them would take quite a long > time. Point taken, although "zfs diff" time is (should) proportional to changes, not to number of files. > How long would it take for (say) rsync to walk two file systems > (or snapshot directories) to come up with the same list? Ten > minutes may seem like a lot in 'absolute' terms, but if something > like rsync takes an hour or two to stat() every file, then it's a > big improvement. "rsync" takes a bit less than 7 minutes. So "zfs diff" is actually slower!. > So the question is: by what metric are you comparing that you came > up with the "disappointing" conclusion? Why is ten minutes > disappointing? What would /not/ be disappointing to you? 8m? 5m? > 3.14 seconds? If I change 10 files in dataset with a trillion files, I would expect less than a couple of seconds. Given the tree walking pruning with "birthdate" age, I actually think this is reasonable (you skip over entire on-disk branches if there are no changes under them). - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBToDmlJlgi5GaxT1NAQKh7QP+OCokqiBNo79Tojtvy9aLztQy0T+mNMoh i5z9BW38h8xdTNHiUqp8qnYaK3c+t8kyl90ZPR42dCKAl3hkk11x695yZuvRp+bm IKO+CPHfQ+wu3G2hoWWwvoHEdiXRvpg2MRZxXXZnzqldthrlq0PtSpNAGctm5Apl Ca564U9dkes= =TeMO -END PGP SIGNATURE- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] "zfs diff" performance disappointing
On Mon, September 26, 2011 14:55, Jesus Cea wrote: [...] > real10m0.272s > user0m0.809s > sys 2m6.693s > """ > > 10 minutes to "diff" 7.55 GB is... disappointing. > > This machine uses a 2-mirror configurations, and there is no more > activity going on in the machine. ZPOOL version 29, ZFS version 5. > > Am I missing anything? [...] Talking about "7.55 GB" is mostly useless as well. If it's a dozen video files then stat()ing them all with be done very quickly by just running find(1). If however the 7.55 GB is made up of 7,550,000 files then going through them would take quite a long time. How long would it take for (say) rsync to walk two file systems (or snapshot directories) to come up with the same list? Ten minutes may seem like a lot in 'absolute' terms, but if something like rsync takes an hour or two to stat() every file, then it's a big improvement. So the question is: by what metric are you comparing that you came up with the "disappointing" conclusion? Why is ten minutes disappointing? What would /not/ be disappointing to you? 8m? 5m? 3.14 seconds? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] "zfs diff" performance disappointing
On Mon, Sep 26, 2011 at 1:55 PM, Jesus Cea wrote: > I just upgraded to Solaris 10 Update 10, and one of the improvements > is "zfs diff". > > Using the "birthtime" of the sectors, I would expect very high > performance. The actual performance doesn't seems better that an > standard "rdiff", though. Quite disappointing... > > Should I disable "atime" to improve "zfs diff" performance? (most data > doesn't change, but "atime" of most files would change). atime has nothing to do with it. How much work zfs diff has to do depends on how much has changed between snapshots. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] "zfs diff" performance disappointing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just upgraded to Solaris 10 Update 10, and one of the improvements is "zfs diff". Using the "birthtime" of the sectors, I would expect very high performance. The actual performance doesn't seems better that an standard "rdiff", though. Quite disappointing... Should I disable "atime" to improve "zfs diff" performance? (most data doesn't change, but "atime" of most files would change). """ [root@buffy backups]# zfs list datos/backups/buffy NAME USED AVAIL REFER MOUNTPOINT datos/backups/buffy 8.95G 553G 7.55G /backups/buffy [root@buffy backups]# time zfs diff -Ft datos/backups/buffy@20110926-20:22 datos/backups/buffy@20110926-20:35 1317061842.659141598M / /backups/buffy/root/proc 1317061812.437869058M / /backups/buffy/root/dev/fd 1317061816.752409624M | /backups/buffy/root/etc/saf/_sacpipe 1317061816.791269117M | /backups/buffy/root/etc/saf/zsmon/_pmpipe 1317061817.291653834M / /backups/buffy/root/etc/svc/volatile 1317061934.727002843M F /backups/buffy/var/adm/lastlog 1317061934.796205623M F /backups/buffy/var/adm/wtmpx 1317061938.764996484M F /backups/buffy/var/ntp/ntpstats/loopstats 1317061938.978388173M F /backups/buffy/var/ntp/ntpstats/peerstats.20110926 real10m0.272s user0m0.809s sys 2m6.693s """ 10 minutes to "diff" 7.55 GB is... disappointing. This machine uses a 2-mirror configurations, and there is no more activity going on in the machine. ZPOOL version 29, ZFS version 5. Am I missing anything? - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBToDKpZlgi5GaxT1NAQJzvQP/YEi58gQe20mYicPFbnrUoC4LU3wu7Evf xA3M+NjXnK8Y8MU9CboIH1+vj8PK7m9lqkZu0N9znAMU5OqDeXmSVBqjRYfJrzBk A4Px9Y1RNA8Dslqm3w8RUdWczIzt4WuyvnjCN8k3YBOMIaVlFQjCQlRjDUDDbzcI tISDPeYzO9w= =ko6a -END PGP SIGNATURE- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs diff cannot stat shares
I had to upgrade zfs zfs upgrade -a then pfexec zfs set sharesmb=off data pfexec zfs set sharesmb=on data after this zfs diff failed with the old snapshots. But with newly created snapshots it worked. Thanks Tim, Dirk -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs diff cannot stat shares
a diff to list the file differences between snapshots http://arc.opensolaris.org/caselog/PSARC/2010/105/mail Dave On 10/13/10 15:48, Edward Ned Harvey wrote: From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of dirk schelfhout Wanted to test the zfs diff command and ran into this. What's zfs diff? I know it's been requested, but AFAIK, not implemented yet. Is that new feature being developed now or something? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs diff cannot stat shares
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of dirk schelfhout > > Wanted to test the zfs diff command and ran into this. What's zfs diff? I know it's been requested, but AFAIK, not implemented yet. Is that new feature being developed now or something? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs diff cannot stat shares
cd /data/.zfs sche...@osolpro:/data/.zfs$ ls -alt ls: cannot access shares: Operation not supported total 4 drwxr-xr-x 19 schelfd staff 25 2010-10-13 18:57 .. dr-xr-xr-x 2 rootroot 2 2010-10-13 17:44 snapshot dr-xr-xr-x 4 rootroot 4 2009-01-28 23:08 . ?? ? ? ? ?? shares sche...@osolpro:/data/.zfs$ pfexec zfs set sharesmb=on data cannot set property for 'data': pool and or dataset must be upgraded to set this property or value sche...@osolpro:/data/.zfs$ pfexec zfs set sharesmb=off data cannot set property for 'data': pool and or dataset must be upgraded to set this property or value sche...@osolpro:/data/.zfs$ pfexec zfs set sharesmb=on data/backup7 sche...@osolpro:/data/.zfs$ cd /backup7/.zfs sche...@osolpro:/backup7/.zfs$ ls -alt total 4 dr-xr-xr-x 2 rootroot 3 2010-10-13 19:26 shares dr-xr-xr-x 2 rootroot 2 2010-10-13 18:35 snapshot drwxr-xr-x 2 schelfd staff 3 2010-08-08 14:52 .. dr-xr-xr-x 4 rootroot 4 2009-09-24 01:32 . sche...@osolpro:/backup7/.zfs$ pfexec zfs set sharesmb=off data/backup7 sche...@osolpro:/backup7/.zfs$ ls -alt total 4 dr-xr-xr-x 2 rootroot 2 2010-10-13 19:27 shares dr-xr-xr-x 2 rootroot 2 2010-10-13 18:35 snapshot drwxr-xr-x 2 schelfd staff 3 2010-08-08 14:52 .. dr-xr-xr-x 4 rootroot 4 2009-09-24 01:32 . -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs diff cannot stat shares
On 10/13/10 10:20 AM, dirk schelfhout wrote: Wanted to test the zfs diff command and ran into this. I turned off all windows sharing. the rpool has normal permissions for .zfs/shares how do I fix this ? Dirk r...@osolpro:/data/.zfs# zfs diff d...@10aug2010 d...@13oct2010 Cannot stat /data/.zfs/shares/: unable to generate diffs pwd /data/.zfs r...@osolpro:/data/.zfs# ls -alt ls: cannot access shares: Operation not supported total 4 dr-xr-xr-x 2 rootroot 2 2010-10-13 17:44 snapshot drwxr-xr-x 18 piet staff 24 2010-10-13 17:44 .. dr-xr-xr-x 4 rootroot 4 2009-01-28 23:08 . What OS bits are you running? -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] zfs diff cannot stat shares
Wanted to test the zfs diff command and ran into this. I turned off all windows sharing. the rpool has normal permissions for .zfs/shares how do I fix this ? Dirk r...@osolpro:/data/.zfs# zfs diff d...@10aug2010 d...@13oct2010 Cannot stat /data/.zfs/shares/: unable to generate diffs pwd /data/.zfs r...@osolpro:/data/.zfs# ls -alt ls: cannot access shares: Operation not supported total 4 dr-xr-xr-x 2 rootroot 2 2010-10-13 17:44 snapshot drwxr-xr-x 18 piet staff 24 2010-10-13 17:44 .. dr-xr-xr-x 4 rootroot 4 2009-01-28 23:08 . -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs diff
> On Mon, Mar 29, 2010 at 5:39 PM, Nicolas Williams > wrote: > > One really good use for zfs diff would be: as a way to index zfs send > > backups by contents. > > Or to generate the list of files for incremental backups via NetBackup > or similar. This is especially important for file systems will > millions of files with relatively few changes. +1 The reason "zfs send" is so fast, is not because it's so fast. It's because it does not need any time to index and compare and analyze which files have changed since the last snapshot or increment. If the "zfs diff" command could generate the list of changed files, and you feed that into tar or whatever, then these 3rd party backup tools become suddenly much more effective. Able to rival the performance of "zfs send." ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs diff
On 03/30/10 12:44 PM, Mike Gerdts wrote: On Mon, Mar 29, 2010 at 5:39 PM, Nicolas Williams wrote: One really good use for zfs diff would be: as a way to index zfs send backups by contents. Or to generate the list of files for incremental backups via NetBackup or similar. This is especially important for file systems will millions of files with relatively few changes. Or to generate the list of files for virus scanning! -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs diff
On 3/29/10 8:02 PM, Daniel Carosone wrote: On Tue, Mar 30, 2010 at 12:37:15PM +1100, Daniel Carosone wrote: There will also need to be clear rules on output ordering, with respect to renames, where multiple changes have happened to renamed files. Separately, but relevant in particular to the above due to the potential for races: what is the defined behaviour when diffing against a live filesystem (rather than a snapshot)? is there an implied snapshot (ie, diff based on content frozen at txg_id when started) or is thhe comparison done against a moving target? It's not just a question of implementation if it can affect the output, especially if it can make it internally inconsistent. -- Dan. Yes, a snapshot is taken and removed once the compare is performed. -tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs diff
On Tue, Mar 30, 2010 at 12:37:15PM +1100, Daniel Carosone wrote: > There will also need to be clear rules on output ordering, with > respect to renames, where multiple changes have happened to renamed > files. Separately, but relevant in particular to the above due to the potential for races: what is the defined behaviour when diffing against a live filesystem (rather than a snapshot)? is there an implied snapshot (ie, diff based on content frozen at txg_id when started) or is thhe comparison done against a moving target? It's not just a question of implementation if it can affect the output, especially if it can make it internally inconsistent. -- Dan. pgpmdu8t9ynKx.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs diff
On Mon, Mar 29, 2010 at 06:38:47PM -0400, David Magda wrote: > A new ARC case: I read this earlier this morning. Welcome news indeed! I have some concerns about the output format, having worked with similar requirements in the past. In particular: as part of the monotone VCS when reporting workspace changes and also as a consumer of similar-purpose output from rsync when building backup catalog databases of what changed each run. I'm not familiar with the ARC process; where should these concerns be directed so as to make a difference? [pun only slightly intended] At the risk of prompting discussion here rather than the right place.. These relate in several ways to the use of the name as the only identifier. For example, it's not clear that the proposed output lets me tell which new filenames are new links to which existing file, or even whether added file names are new files or just new links. There will also need to be clear rules on output ordering, with respect to renames, where multiple changes have happened to renamed files. Some of these concerns might be better addressed with clearer examples / use cases. Consider the commmon case of a file having been replaced with another: say, an editor that renames the old file and creates and rewrites a new file with the same name. It may remove the old, or keep it as a "backup" and maybe delete the previous backup. Would this be reported as a series of renames and adds and deletes (tracking the node), or merely as a content change (tracking the name)? Now consider that the file may have had links. I'm concerned that the proposed output format does not represent this and similar cases well. I realise it's not intended to convey all of the details of what changed, merely to flag which files should be checked for further information. I also think distinguishing content-change from attribute-change (e.g. chmod/chown) would be highly useful to potential consumers. -- Dan. pgp2ES92zFu3U.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs diff
On 03/29/10 16:44, Mike Gerdts wrote: On Mon, Mar 29, 2010 at 5:39 PM, Nicolas Williams wrote: One really good use for zfs diff would be: as a way to index zfs send backups by contents. Or to generate the list of files for incremental backups via NetBackup or similar. This is especially important for file systems will millions of files with relatively few changes. Or to say keep indexing files on your desktop This gives everyone a way to access the changes in a filesystem order (number of files changed) instead of order(number of files extant). - Bart -- Bart Smaalders Solaris Kernel Performance bart.smaald...@oracle.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs diff
On Mon, Mar 29, 2010 at 5:39 PM, Nicolas Williams wrote: > One really good use for zfs diff would be: as a way to index zfs send > backups by contents. Or to generate the list of files for incremental backups via NetBackup or similar. This is especially important for file systems will millions of files with relatively few changes. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs diff
On 30-3-2010 0:39, Nicolas Williams wrote: > One really good use for zfs diff would be: as a way to index zfs send > backups by contents. > > Nico > Any prevision about the release target? snv_13x? Bruno 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] zfs diff
zfs diff is incredibly cool. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs diff
One really good use for zfs diff would be: as a way to index zfs send backups by contents. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] zfs diff
A new ARC case: There is a long-standing RFE for zfs to be able to describe what has changed between the snapshots of a dataset. To provide this capability, we propose a new 'zfs diff' sub-command. When run with appropriate privilege the sub-command describes what file system level changes have occurred between the requested snapshots. A diff between the current version of the file system and one of its snapshots is also supported. Five types of change are described: oFile/Directory modified oFile/Directory present in older snapshot but not newer oFile/Directory present in newer snapshot but not older oFile/Directory renamed oFile link count changed http://arc.opensolaris.org/caselog/PSARC/2010/105/ Via c0t0d0s0.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] zfs diff @snap1 @snap2
Hi Is it possible to see what changed between two snapshots (efficiently) ? I tried to take a look what "zfs send -i" does, and I found that it operates at very low (dmu) level and basically dumps the blocks. Any pointers on extracting inode info from this stream or otherwise ? - mritun This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
