Re: [zfs-discuss] Wanted: sanity check for a clustered ZFS idea

On Tue, Oct 11, 2011 at 11:15 PM, Richard Elling wrote: > On Oct 9, 2011, at 10:28 AM, Jim Klimov wrote: >> ZFS developers have for a long time stated that ZFS is not intended, >> at least not in near term, for clustered environments (that is, having >> a pool safely imported by several nodes simu

Re: [zfs-discuss] Wanted: sanity check for a clustered ZFS idea

On Sun, Oct 9, 2011 at 12:28 PM, Jim Klimov wrote: > So, one version of the solution would be to have a single host > which imports the pool in read-write mode (i.e. the first one > which boots), and other hosts would write thru it (like iSCSI > or whatever; maybe using SAS or FC to connect betwee

Re: [zfs-discuss] Wanted: sanity check for a clustered ZFS idea

On Thu, Oct 13, 2011 at 9:13 PM, Jim Klimov wrote: > Thanks to Nico for concerns about POSIX locking. However, > hopefully, in the usecase I described - serving images of > VMs in a manner where storage, access and migration are > efficient - whole datasets (be it volumes or FS datasets) > can be

Re: [zfs-discuss] Wanted: sanity check for a clustered ZFS idea

Also, it's not worth doing a clustered ZFS thing that is too application-specific. You really want to nail down your choices of semantics, explore what design options those yield (or approach from the other direction, or both), and so on. Nico -- ___ zf

Re: [zfs-discuss] about btrfs and zfs

On Tue, Oct 18, 2011 at 9:35 AM, Brian Wilson wrote: > I just wanted to add something on fsck on ZFS - because for me that used to > make ZFS 'not ready for prime-time' in 24x7 5+ 9s uptime environments. > Where ZFS doesn't have an fsck command - and that really used to bug me - it > does now have

Re: [zfs-discuss] about btrfs and zfs

On Wed, Oct 19, 2011 at 7:24 AM, Garrett D'Amore wrote: > I'd argue that from a *developer* point of view, an fsck tool for ZFS might > well be useful.  Isn't that what zdb is for? :-) > > But ordinary administrative users should never need something like this, > unless they have encountered a b

Re: [zfs-discuss] Wanted: sanity check for a clustered ZFS idea

To some people "active-active" means all cluster members serve the same filesystems. To others "active-active" means all cluster members serve some filesystems and can serve all filesystems ultimately by taking over failed cluster members. Nico -- ___ z

Re: [zfs-discuss] about btrfs and zfs

On Fri, Nov 11, 2011 at 4:27 PM, Paul Kraus wrote: > The command syntax paradigm of zfs (command sub-command object > parameters) is not unique to zfs, but seems to have been the "way of > doing things" in Solaris 10. The _new_ functions of Solaris 10 were > all this way (to the best of my knowled

Re: [zfs-discuss] about btrfs and zfs

On Mon, Nov 14, 2011 at 8:33 AM, Edward Ned Harvey wrote: >> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- >> boun...@opensolaris.org] On Behalf Of Paul Kraus >> >> Is it really B-Tree based? Apple's HFS+ is B-Tree based and falls >> apart (in terms of performance) when you get to

[zfs-discuss] aclmode=mask

I see, with great pleasure, that ZFS in Solaris 11 has a new aclmode=mask property. http://download.oracle.com/docs/cd/E23824_01/html/821-1448/gbscy.html#gkkkp http://download.oracle.com/docs/cd/E23824_01/html/821-1448/gbchf.html#gljyz http://download.oracle.com/docs/cd/E23824_01/html/821-1462/zfs

Re: [zfs-discuss] aclmode=mask

On Mon, Nov 14, 2011 at 6:20 PM, Nico Williams wrote: > I see, with great pleasure, that ZFS in Solaris 11 has a new > aclmode=mask property. Also, congratulations on shipping. And thank you for implementing aclmode=mask. Nico -- ___ zfs-d

Re: [zfs-discuss] virtualbox rawdisk discrepancy

Moving boot disks from one machine to another used to work as long as the machines were of the same architecture. I don't recall if it was *supported* (and wouldn't want to pretend to speak for Oracle now), but it was meant to work (unless you minimized the install and removed drivers not needed o

Re: [zfs-discuss] grrr, How to get rid of mis-touched file named `-c'

On Mon, Nov 28, 2011 at 11:28 AM, Smith, David W. wrote: > You could list by inode, then use find with rm. > > # ls -i > 7223 -O > > # find . -inum 7223 -exec rm {} \; This is the one solution I'd recommend against, since it would remove hardlinks that you might care about. Also, this thread is

Re: [zfs-discuss] bug moving files between two zfs filesystems (too many open files)

On Tue, Nov 29, 2011 at 12:17 PM, Cindy Swearingen wrote: > I think the "too many open files" is a generic error message about running > out of file descriptors. You should check your shell ulimit > information. Also, see how many open files you have: echo /proc/self/fd/* It'd be quite weird tho

Re: [zfs-discuss] Improving L1ARC cache efficiency with dedup

On Dec 11, 2011 5:12 AM, "Nathan Kroenert" wrote: > > On 12/11/11 01:05 AM, Pawel Jakub Dawidek wrote: >> >> On Wed, Dec 07, 2011 at 10:48:43PM +0200, Mertol Ozyoney wrote: >>> >>> Unfortunetly the answer is no. Neither l1 nor l2 cache is dedup aware. >>> >>> The only vendor i know that can do th

Re: [zfs-discuss] S11 vs illumos zfs compatiblity

On Tue, Dec 27, 2011 at 2:20 PM, Frank Cusack wrote: > > >> If I "upgrade" ZFS to use the new features in Solaris 11 I will be unable >> to import my pool using the free ZFS implementation that is available in >> illumos base

Re: [zfs-discuss] S11 vs illumos zfs compatiblity

On Tue, Dec 27, 2011 at 8:44 PM, Frank Cusack wrote: > So with a de facto fork (illumos) now in place, is it possible that two > zpools will report the same version yet be incompatible across > implementations? Not likely: the Illumos community has developed a method for managing ZFS extensions i

Re: [zfs-discuss] Improving L1ARC cache efficiency with dedup

On Wed, Dec 28, 2011 at 3:14 PM, Brad Diggs wrote: > > The two key takeaways from this exercise were as follows.  There is > tremendous caching potential > through the use of ZFS deduplication.  However, the current block level > deduplication does not > benefit directory as much as it perhaps c

Re: [zfs-discuss] Improving L1ARC cache efficiency with dedup

On Thu, Dec 29, 2011 at 9:53 AM, Brad Diggs wrote: > Jim, > > You are spot on.  I was hoping that the writes would be close enough to > identical that > there would be a high ratio of duplicate data since I use the same record > size, page size, > compression algorithm, … etc.  However, that was

Re: [zfs-discuss] S11 vs illumos zfs compatiblity

On Thu, Dec 29, 2011 at 2:06 PM, sol wrote: > Richard Elling wrote: >> many of the former Sun ZFS team >> regularly contribute to ZFS through the illumos developer community. > > Does this mean that if they provide a bug fix via illumos then the fix won't > make it into the Oracle code? If you're

Re: [zfs-discuss] Improving L1ARC cache efficiency with dedup

On Thu, Dec 29, 2011 at 6:44 PM, Matthew Ahrens wrote: > On Mon, Dec 12, 2011 at 11:04 PM, Erik Trimble wrote: >> (1) when constructing the stream, every time a block is read from a fileset >> (or volume), its checksum is sent to the receiving machine. The receiving >> machine then looks up that

Re: [zfs-discuss] S11 vs illumos zfs compatiblity

On Thu, Jan 5, 2012 at 8:53 AM, sol wrote: >> if a bug fixed in Illumos is never reported to Oracle by a customer, >> it would likely never get fixed in Solaris either > > :-( > > I would have liked to think that there was some good-will between the ex- and > current-members of the zfs team, in t

Re: [zfs-discuss] Idea: ZFS and on-disk ECC for blocks

On Wed, Jan 11, 2012 at 9:16 AM, Jim Klimov wrote: > I've recently had a sort of an opposite thought: yes, > ZFS redundancy is good - but also expensive in terms > of raw disk space. This is especially bad for hardware > space-constrained systems like laptops and home-NASes, > where doubling the n

Re: [zfs-discuss] Data loss by memory corruption?

On Wed, Jan 18, 2012 at 4:53 AM, Jim Klimov wrote: > 2012-01-18 1:20, Stefan Ring wrote: >> I don’t care too much if a single document gets corrupted – there’ll >> always be a good copy in a snapshot. I do care however if a whole >> directory branch or old snapshots were to disappear. > > Well, as

Re: [zfs-discuss] ZFS on Linux vs FreeBSD

As I understand it LLNL has very large datasets on ZFS on Linux. You could inquire with them, as well as http://groups.google.com/a/zfsonlinux.org/group/zfs-discuss/topics?pli=1 . My guess is that it's quite stable for at least some use cases (most likely: LLNL's!), but that may not be yours. Yo

Re: [zfs-discuss] cluster vs nfs (was: Re: ZFS on Linux vs FreeBSD)

I agree, you need something like AFS, Lustre, or pNFS. And/or an NFS proxy to those. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] cluster vs nfs (was: Re: ZFS on Linux vs FreeBSD)

On Wed, Apr 25, 2012 at 4:26 PM, Paul Archer wrote: > 2:20pm, Richard Elling wrote: >> Ignoring lame NFS clients, how is that architecture different than what >> you would have >> with any other distributed file system? If all nodes share data to all >> other nodes, then...? > > Simple. With a dis

Re: [zfs-discuss] cluster vs nfs (was: Re: ZFS on Linux vs FreeBSD)

On Wed, Apr 25, 2012 at 5:22 PM, Richard Elling wrote: > Unified namespace doesn't relieve you of 240 cross-mounts (or equivalents). > FWIW, > automounters were invented 20+ years ago to handle this in a nearly seamless > manner. > Today, we have DFS from Microsoft and NFS referrals that almost el

Re: [zfs-discuss] cluster vs nfs

On Wed, Apr 25, 2012 at 5:42 PM, Ian Collins wrote: > Aren't those general considerations when specifying a file server? There are Lustre clusters with thousands of nodes, hundreds of them being servers, and high utilization rates. Whatever specs you might have for one server head will not meet

Re: [zfs-discuss] cluster vs nfs (was: Re: ZFS on Linux vs FreeBSD)

On Wed, Apr 25, 2012 at 7:37 PM, Richard Elling wrote: > On Apr 25, 2012, at 3:36 PM, Nico Williams wrote: > > I disagree vehemently.  automount is a disaster because you need to > > synchronize changes with all those clients.  That's not realistic. > > Really?  I did

Re: [zfs-discuss] cluster vs nfs (was: Re: ZFS on Linux vs FreeBSD)

On Wed, Apr 25, 2012 at 8:57 PM, Paul Kraus wrote: > On Wed, Apr 25, 2012 at 9:07 PM, Nico Williams wrote: >> Nothing's changed.  Automounter + data migration -> rebooting clients >> (or close enough to rebooting).  I.e., outage. > >    Uhhh, not if you design

Re: [zfs-discuss] cluster vs nfs

On Thu, Apr 26, 2012 at 12:10 AM, Richard Elling wrote: > On Apr 25, 2012, at 8:30 PM, Carson Gaspar wrote: > Reboot requirement is a lame client implementation. And lame protocol design. You could possibly migrate read-write NFSv3 on the fly by preserving FHs and somehow updating the clients to

Re: [zfs-discuss] cluster vs nfs

On Thu, Apr 26, 2012 at 5:45 PM, Carson Gaspar wrote: > On 4/26/12 2:17 PM, J.P. King wrote: >> I don't know SnapMirror, so I may be mistaken, but I don't see how you >> can have non-synchronous replication which can allow for seamless client >> failover (in the general case). Technically this doe

Re: [zfs-discuss] cluster vs nfs

On Thu, Apr 26, 2012 at 12:37 PM, Richard Elling wrote: > [...] NFSv4 had migration in the protocol (excluding protocols between servers) from the get-go, but it was missing a lot (FedFS) and was not implemented until recently. I've no idea what clients and servers support it adequately besides

Re: [zfs-discuss] current status of SAM-QFS?

On Wed, May 2, 2012 at 7:59 AM, Paul Kraus wrote: > On Wed, May 2, 2012 at 7:46 AM, Darren J Moffat > wrote: > If Oracle is only willing to share (public) information about the > roadmap for products via official sales channels then there will be > lots of FUD in the market. Now, as to sharing f

Re: [zfs-discuss] Terminology question on ZFS COW

COW goes back at least to the early days of virtual memory and fork(). On fork() the kernel would arrange for writable pages in the parent process to be made read-only so that writes to them could be caught and then the page fault handler would copy the page (and restore write access) so the paren

Re: [zfs-discuss] Is there an actual newsgroup for zfs-discuss?

On Mon, Jun 11, 2012 at 5:05 PM, Tomas Forsman wrote: > .. or use a mail reader that doesn't suck. Or the mailman thread view. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] [developer] Re: History of EPERM for unlink() of directories on ZFS?

On Tue, Jun 26, 2012 at 9:44 AM, Alan Coopersmith wrote: > On 06/26/12 05:46 AM, Lionel Cons wrote: >> On 25 June 2012 11:33,   wrote: >>> To be honest, I think we should also remove this from all other >>> filesystems and I think ZFS was created this way because all modern >>> filesystems do it t

Re: [zfs-discuss] History of EPERM for unlink() of directories on ZFS?

On Tue, Jun 26, 2012 at 8:12 AM, Lionel Cons wrote: > On 26 June 2012 14:51,   wrote: > We've already asked our Netapp representative. She said it's not hard > to add that. Did NetApp tell you that they'll add support for using the NFSv4 LINK operation on source objects that are directories?! I'

Re: [zfs-discuss] Interaction between ZFS intent log and mmap'd files

On Mon, Jul 2, 2012 at 3:32 PM, Bob Friesenhahn wrote: > On Mon, 2 Jul 2012, Iwan Aucamp wrote: >> I'm interested in some more detail on how ZFS intent log behaves for >> updated done via a memory mapped file - i.e. will the ZIL log updates done >> to an mmap'd file or not ? > > > I would to expec

Re: [zfs-discuss] Interaction between ZFS intent log and mmap'd files

On Tue, Jul 3, 2012 at 9:48 AM, James Litchfield wrote: > On 07/02/12 15:00, Nico Williams wrote: >> You can't count on any writes to mmap(2)ed files hitting disk until >> you msync(2) with MS_SYNC. The system should want to wait as long as >> possible before committing

Re: [zfs-discuss] Interaction between ZFS intent log and mmap'd files

On Wed, Jul 4, 2012 at 11:14 AM, Bob Friesenhahn wrote: > On Tue, 3 Jul 2012, James Litchfield wrote: >> Agreed - msync/munmap is the only guarantee. > > I don't see that the munmap definition assures that anything is written to > "disk". The system is free to buffer the data in RAM as long as it

Re: [zfs-discuss] New fast hash algorithm - is it needed?

On Wed, Jul 11, 2012 at 9:48 AM, wrote: >>Huge space, but still finite=85 > > Dan Brown seems to think so in "Digital Fortress" but it just means he > has no grasp on "big numbers". I couldn't get past that. I had to put the book down. I'm guessing it was as awful as it threatened to be. IMO,

Re: [zfs-discuss] New fast hash algorithm - is it needed?

On Wed, Jul 11, 2012 at 3:45 AM, Sašo Kiselkov wrote: > It's also possible to set "dedup=verify" with "checksum=sha256", > however, that makes little sense (as the chances of getting a random > hash collision are essentially nil). IMO dedup should always verify. Nico -- _

Re: [zfs-discuss] New fast hash algorithm - is it needed?

You can treat whatever hash function as an idealized one, but actual hash functions aren't. There may well be as-yet-undiscovered input bit pattern ranges where there's a large density of collisions in some hash function, and indeed, since our hash functions aren't ideal, there must be. We just d

Re: [zfs-discuss] Can the ZFS "copies" attribute substitute HW disk redundancy?

The copies thing is a really only for laptops, where the likelihood of redundancy is very low (there are some high-end laptops with multiple drives, but those are relatively rare) and where this idea is better than nothing. It's also nice that copies can be set on a per-dataset manner (whereas RAI

Re: [zfs-discuss] Solaris 11 System Reboots Continuously Because of a ZFS-Related Panic (7191375)

On Mon, Jan 14, 2013 at 1:48 PM, Tomas Forsman wrote: >> https://bug.oraclecorp.com/pls/bug/webbug_print.show?c_rptno=15852599 > > Host oraclecorp.com not found: 3(NXDOMAIN) > > Would oracle.internal be a better domain name? Things like that cannot be changed easily. They (Oracle) are stuck with

Re: [zfs-discuss] RFE: Un-dedup for unique blocks

I've wanted a system where dedup applies only to blocks being written that have a good chance of being dups of others. I think one way to do this would be to keep a scalable Bloom filter (on disk) into which one inserts block hashes. To decide if a block needs dedup one would first check the Bloo

Re: [zfs-discuss] RFE: Un-dedup for unique blocks

Bloom filters are very small, that's the difference. You might only need a few bits per block for a Bloom filter. Compare to the size of a DDT entry. A Bloom filter could be cached entirely in main memory. ___ zfs-discuss mailing list zfs-discuss@opens

Re: [zfs-discuss] RFE: Un-dedup for unique blocks

IIRC dump is special. As for swap... really, you don't want to swap. If you're swapping you have problems. Any swap space you have is to help you detect those problems and correct them before apps start getting ENOMEM. There *are* exceptions to this, such as Varnish. For Varnish and any other

Re: [zfs-discuss] Understanding directio, O_DSYNC and zfs_nocacheflush on ZFS

On Mon, Feb 7, 2011 at 1:17 PM, Yi Zhang wrote: > On Mon, Feb 7, 2011 at 1:51 PM, Brandon High wrote: > Maybe I didn't make my intention clear. UFS with directio is > reasonably close to a raw disk from my application's perspective: when > the app writes to a file location, no buffering happens.

Re: [zfs-discuss] RAID Failure Calculator (for 8x 2TB RAIDZ)

On Feb 14, 2011 6:56 AM, "Paul Kraus" wrote: > P.S. I am measuring number of objects via `zdb -d` as that is faster > than trying to count files and directories and I expect is a much > better measure of what the underlying zfs code is dealing with (a > particular dataset may have lots of snapshot

Re: [zfs-discuss] disable zfs/zpool destroy for root user

On Thu, Feb 17, 2011 at 3:07 PM, Richard Elling wrote: > On Feb 17, 2011, at 12:44 PM, Stefan Dormayer wrote: > >> Hi all, >> >> is there a way to disable the subcommand destroy of zpool/zfs for the root >> user? > > Which OS? Heheh. Great answer. The real answer depends also on what the OP me

Re: [zfs-discuss] ls reports incorrect file size

Also, sparseness need not be apparent to applications. Until recent improvements to lseek(2) to expose hole/non-hole offsets, the only way to know about sparseness was to notice that a file's reported size is more than the file's reported filesystem blocks times the block size. Sparse files in Uni

Re: [zfs-discuss] ls reports incorrect file size

On Mon, May 2, 2011 at 3:56 PM, Eric D. Mudama wrote: > Yea, kept googling and it makes sense.  I guess I am simply surprised > that the application would have done the seek+write combination, since > on NTFS (which doesn't support sparse) these would have been real > 1.5GB files, and there would

Re: [zfs-discuss] ls reports incorrect file size

Then again, Windows apps may be doing seek+write to pre-allocate storage. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] [cryptography] rolling hashes, EDC/ECC vs MAC/MIC, etc.

On Sun, May 22, 2011 at 10:20 AM, Richard Elling wrote: > ZFS already tracks the blocks that have been written, and the time that > they were written. So we already know when something was writtem, though > that does not answer the question of whether the data was changed. I think > it is a pretty

Re: [zfs-discuss] [cryptography] rolling hashes, EDC/ECC vs MAC/MIC, etc.

On Sun, May 22, 2011 at 1:52 PM, Nico Williams wrote: > [...] Or perhaps you'll argue that no one should ever need bi-di > replication, that if one finds oneself wanting that then one has taken > a wrong turn somewhere. You could also grant the premise and argue instead th

Re: [zfs-discuss] ZFS, Oracle and Nexenta

On May 25, 2011 7:15 AM, "Garrett D'Amore" wrote: > > You are welcome to your beliefs. There are many groups that do standards that do not meet in public. [...] True. > [...] In fact, I can't think of any standards bodies that *do* hold open meetings. I can: the IETF, for example. All busin

Re: [zfs-discuss] ZFS Hard link space savings

On Sun, Jun 12, 2011 at 4:14 PM, Scott Lawson wrote: > I have an interesting question that may or may not be answerable from some > internal > ZFS semantics. This is really standard Unix filesystem semantics. > [...] > > So total storage used is around ~7.5MB due to the hard linking taking place

Re: [zfs-discuss] ZFS Hard link space savings

On Mon, Jun 13, 2011 at 5:50 AM, Roy Sigurd Karlsbakk wrote: >> If anyone has any ideas be it ZFS based or any useful scripts that >> could help here, I am all ears. > > Something like this one-liner will show what would be allocated by everything > if hardlinks weren't used: > > # size=0; for i

Re: [zfs-discuss] ZFS Hard link space savings

On Mon, Jun 13, 2011 at 12:59 PM, Nico Williams wrote: > Try this instead: > > (echo 0; find . -type f \! -links 1 | xargs stat -c " %b %B *+" $p; echo p) | > dc s/\$p// ___ zfs-discuss mailing list zfs-discus

Re: [zfs-discuss] ZFS Hard link space savings

And, without a sub-shell: find . -type f \! -links 1 | xargs stat -c " %b %B *+p" /dev/null | dc 2>/dev/null | tail -1 (The stderr redirection is because otherwise dc whines once that the stack is empty, and the tail is because we print interim totals as we go.) Also, this doesn't quit work, sin

Re: [zfs-discuss] Versioning FS was: question about COW and snapshots

As Casper pointed out, the right thing to do is to build applications such that they can detect mid-transaction state and roll it back (or forward, if there's enough data). Then mid-transaction snapshots are fine, and the lack of APIs by which to inform the filesystem of application transaction bo

Re: [zfs-discuss] question about COW and snapshots

On Thu, Jun 16, 2011 at 8:51 AM, wrote: > If a database engine or another application keeps both the data and the > log in the same filesystem, a snapshot wouldn't create inconsistent data > (I think this would be true with vim and a large number of database > engines; vim will detect the swap fi

Re: [zfs-discuss] question about COW and snapshots

That said, losing committed transactions when you needed and thought you had ACID semantics... is bad. But that's implied in any restore-from-backups situation. So you replicate/distribute transactions so that restore from backups (or snapshots) is an absolutely last resort matter, and if you eve

Re: [zfs-discuss] Encryption accelerator card recommendations.

IMO a faster processor with built-in AES and other crypto support is most likely to give you the most bang for your buck, particularly if you're using closed Solaris 11, as Solaris engineering is likely to add support for new crypto instructions faster than Illumos (but I don't really know enough a

Re: [zfs-discuss] Encryption accelerator card recommendations.

On Jun 27, 2011 9:24 PM, "David Magda" wrote: > AESNI is certain better than nothing, but RSA, SHA, and the RNG would be nice as well. It'd also be handy for ZFS crypto in addition to all the network IO stuff. The most important reason for AES-NI might be not performance but defeating side-channe

Re: [zfs-discuss] Encryption accelerator card recommendations.

On Jun 27, 2011 4:15 PM, "David Magda" wrote: > The (Ultra)SPARC T-series processors do, but to a certain extent it goes > against a CPU manufacturers best (financial) interest to provide this: > crypto is very CPU intensive using 'regular' instructions, so if you need > to do a lot of it, it woul

Re: [zfs-discuss] Summary: Dedup memory and performance (again, again)

On Jul 9, 2011 1:56 PM, "Edward Ned Harvey" < opensolarisisdeadlongliveopensola...@nedharvey.com> wrote: > > Given the abysmal performance, I have to assume there is a significant > number of "overhead" reads or writes in order to maintain the DDT for each > "actual" block write operation. Somethi

Re: [zfs-discuss] SSD vs "hybrid" drive - any advice?

On Wed, Jul 27, 2011 at 9:22 PM, Daniel Carosone wrote: > Absent TRIM support, there's another way to do this, too.  It's pretty > easy to dd /dev/zero to a file now and then.  Just make sure zfs > doesn't prevent these being written to the SSD (compress and dedup are > off).  I have a separate "f

Re: [zfs-discuss] zfs scripts

On Fri, Sep 9, 2011 at 5:33 AM, Sriram Narayanan wrote: > Plus, you'll need an & character at the end of each command. And a wait command, if you want the script to wait for the sends to finish (which you should). Nico -- ___ zfs-discuss mailing list z

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

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