On Tue, Jun 30, 2009 at 09:08:17AM -0700, Jeremy Archer wrote:
> Hi Darren,
>
> Thanks for replying.
>
> I am confused then. What is the purpose of incorporating the birth txg
> in the arc hash?
Consider:
TXG action
5 write of first block of File A, assigned DVA
On Wed, Jun 24, 2009 at 10:58:49AM -0700, Marcelo Leal wrote:
> Hello Jonathan,
> You are saying that the SEEK_HOLE and SEEK_DATA are implemented on
> the "birth_txg" and not on the "fill_count"?
Um, no, I don't think so. I was just saying that for most people checking for
holes, they use "blk_
On Mon, Jun 22, 2009 at 02:28:25PM -0700, Jeremy Archer wrote:
>
> Also: what is BP_IS_HOLE? I see it has no birth_txg.
A "HOLE" BP is similar to a NULL pointer; it doesn't point to anything, and
is used to indicate there is no data underneath that block pointer. The
representation is all-zeros
On Thu, Jun 18, 2009 at 10:57:45AM -0700, Steve Gonczi wrote:
> I managed to get the ztest debug compile, using the technique written up in
> this thread.
>
> One thing is still not working: Trying to apply the same methodology to an
> userland
> command (e.g. fashioning a debug-able zpool co
On Mon, Jun 15, 2009 at 04:58:27PM -0700, Steve Gonczi wrote:
> I see.
>
> The first number (which I always assumed was just
> the numeric equivalent of the function+offset shown in the next column)
> is the frame pointer for the associated stack frame.
>
> Presumably, the first line findsta
On Mon, Jun 15, 2009 at 02:35:10PM -0700, Steve Gonczi wrote:
> > My experience with the gdb protocol has been very
> > negative; it's
> > very poorly designed, and prone to breakage.
>
> And, with a little luck, nobody from the GNU camp is reading this list :-)
I think my experience is all wel
On Mon, Jun 15, 2009 at 12:10:12PM -0700, Steve Gonczi wrote:
> Absolutely no disrespect to mdb, I love the thing for kernel/assembler
> debugging.
>
> However, stepping through source code, walking the stack frames,
> seeing local variables effortlessly is still a significant plus.
>
> What I woul
On Fri, Jun 12, 2009 at 03:04:55PM -0700, Steve Gonczi wrote:
> I did the full nightly, then edited the Makefile.master debug setting so it
> generates dwarf debug info. Killed the CTF* utilities as outlined
> previously in this thread.
> Recompiled libzpool and libzfs from their usr/src/li
On Thu, May 21, 2009 at 10:59:56AM -0700, Johan Eliasson wrote:
> I seem to be in that very situation right now. Trying to mirror the
> rpool on my new SuperMicro X7SBA mobo, I have two 320GB SATA-disks. No
> matter what I do I seem to get the EFI label complaint I
> installed the system on th
On Thu, May 21, 2009 at 09:06:48AM -0700, Johan Eliasson wrote:
> And yet the recommendation is to not use slices with ZFS but whole
> disks. This is very conflicting..
In general, this is true. For root pools, we're constrained to what BIOSes
support, and most do not support EFI labels.
Che
On Sun, May 03, 2009 at 12:53:31PM -0700, paul wrote:
> Very nice; and ultimately will be very interesting to see what
> percentage of checksum errors within a particular deployment turn out
> to most likely be correctable single bit errors. (And thereby possibly
> even measurably help improve the
Hi all,
Just a quick note; with a fletcher-4 checksum (the current version), the
following algorithm determines the position of any single-bit error.
bool
has_1bit_err(zio_cksum_t *base, zio_cksum_t *bad, size_t bufsize, int bswap)
{
uint64_t a, b, c, d;
int neg;
size_t n
On Mon, Apr 13, 2009 at 06:34:36PM -0700, paul wrote:
> Nice analysis. I understand you've found on the
> processor/memory-subsystem architecture you've experimented with, that
> if the data being summed isn't already cached, it's access will likely
> dominate it's use in calculations:
>
> - Altho
On Tue, Mar 31, 2009 at 09:07:31AM -0700, paul wrote:
> Nice.
>
> As a minor thought with respect to naming conventions, as most
> aren't likely to bother attempting to understand the relative merits
> of available checksum implementations, I can't help but wonder
> if the naming conventions shoul
On Tue, Feb 03, 2009 at 12:51:27AM -0800, Handojo wrote:
> Dear ZFS experts,
> handojoh at opensolaris:~# zpool add rpool c4d0
> cannot label 'c4d0': EFI labeled devices are not supported on root pools.
I think you want:
zpool attach rpool c3d0s0 c4d0s0
That will create a mirror; ("add" would m
On Mon, Aug 18, 2008 at 04:41:35PM -0700, paul wrote:
> CORRECTION: As fletcher4 actually sums 32bit (not 64bit) data using 64bit
> accumulators,
> the first two checksum terms (a and b) will not overflow for data block sizes
> as large as
> 128KB, and therefore should be considered at least as s
wlock.c#_rw_read_held
it checks the current thread's list of locks to verify that it is not being
held.
> Oh well... now I only have to figure out a way to emulate this with POSIX
> threads.. :)
It's much easier with help from the implementation; you could just disable
that single assert.
Cheers,
- jonathan
--
Jonathan Adams, Solaris Kernel Development
17 matches
Mail list logo
