Re: [zfs-discuss] Metadata (DDT) Cache Bias
On Jun 3, 2011, at 6:25 AM, Roch wrote: > > Edward Ned Harvey writes: >> Based on observed behavior measuring performance of dedup, I would say, some >> chunk of data and its associated metadata seem have approximately the same >> "warmness" in the cache. So when the data gets evicted, the associated >> metadata tends to be evicted too. So whenever you have a cache miss, >> instead of needing to fetch 1 thing from disk (the data) you need to fetch N >> things from disk (data + the metadata.) >> >> >> >> I would say, simply giving bias to the metadata would be useful. So the >> metadata would tend to stay in cache, even when the data itself is evicted. >> Useful because the metadata is so *darn* small by comparison with the actual >> data... It carries a relatively small footprint in ram, but upon cache >> miss, it more than doubles the disk fetch penalty. >> >> >> >> If you consider the extreme bias... If the system would never give up >> metadata in cache until all the cached data were gone... Then it would be >> similar to the current primarycache=metadata, except that the system would >> be willing to cache data too, whenever there was available cache otherwise >> going to waste. >> >> > > Interesting. Now consider this : > > We have an indirect block in memory (those are 16K > referencing 128 individual data blocks). We also have an > unrelated data block say 16K. Neither are currently being > reference nor have they been for a long time (otherwise they > move up to the head of the cache lists). They reach the > tail of the primary cache together. I have room for one of > them in the secondary cache. > > Absent other information, do we think that the indirect > block is more valuable than the data block ? At first I also > wanted to say that metadata should be favored. Now I can't come > up with an argument to favor either one. Therefore I think > we need to include more information than just data vs > metadata in the decision process. > > Instant Poll : Yes/No ? No. Methinks the MRU/MFU balance algorithm adjustment is more fruitful. -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] compare snapshot to current zfs fs
Andrew Gabriel writes: > Harry Putnam wrote: >> I have a sneaking feeling I'm missing something really obvious. >> >> If you have zfs fs that see little use and have lost track of whether >> changes may have occurred since last snapshot, is there some handy way >> to determine if a snapshot matches its filesystem. Or put another >> way, some way to determine if the snapshot is different than its >> current filesystem. >> >> I knot about the diff tools and of course I guess one could compare >> overall sizes in bytes for a good idea, but is there a way provided by >> zfs? >> > > If you have a recent enough OS release... > > zfs diff [ | ] Apparently my OS is new enough (b 147 )... since the command is known. Very nice... but where is the documentation? `man zfs' has no hits on a grep for diff (except different..) Ahh never mind... I found: http://www.c0t0d0s0.org/archives/6829-zfs-diff-in-Opensolaris.html Which tells all about it but apparently too new to be in the man page yet? The date there is Aug of 2010... thats kind of a good while ago. The ones with `+' are added... and a very nice way to get such a list. But I also see a massive list of files with a letter `m' prefixed on each line, Which is supposed to mean modified, They cannot all really be modified so I'm thinking its something to do with rsyncing files from a windows XP machine to Openindiana.. is that likely? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] compare snapshot to current zfs fs
Harry Putnam wrote: I have a sneaking feeling I'm missing something really obvious. If you have zfs fs that see little use and have lost track of whether changes may have occurred since last snapshot, is there some handy way to determine if a snapshot matches its filesystem. Or put another way, some way to determine if the snapshot is different than its current filesystem. I knot about the diff tools and of course I guess one could compare overall sizes in bytes for a good idea, but is there a way provided by zfs? If you have a recent enough OS release... zfs diff [ | ] -- Andrew Gabriel ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] compare snapshot to current zfs fs
I have a sneaking feeling I'm missing something really obvious. If you have zfs fs that see little use and have lost track of whether changes may have occurred since last snapshot, is there some handy way to determine if a snapshot matches its filesystem. Or put another way, some way to determine if the snapshot is different than its current filesystem. I knot about the diff tools and of course I guess one could compare overall sizes in bytes for a good idea, but is there a way provided by zfs? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] [OpenIndiana-discuss] Another zfs issue
> > Yeah, this is a known problem. The DTL on the toplevel shows an > > outage, and is preventing the removal of the spare even though > > removing the spare won't make the outage worse. > > > > Unfortunately, for opensolaris anyway, there is no workaround. > > > > You could try doing a full scrub, replacing any disks that show > > errors, and waiting for the resilver to complete. That may clean up > > the DTL enough to detach the spare. > > I'm not familiar with the DTL term, but does this mean, in English, > that if data errors are found and are not correctable, they will stay? > If so, is there another workaround than upgrading to something? Is > this bug still in s11ex? Can someone please fill me in on how this problem can be fixed? Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 97542685 r...@karlsbakk.net http://blogg.karlsbakk.net/ -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
