The dva is just part of a block pointer blkptr_t.
It's the blkptr_t that is stored on disk and used to traverse the pool.
It also contains such details as the block size, ditto dvas (redundant
blocks), the birth txg, block checksum, endianess, ...
Neil.
Jeremy Archer wrote:
> Hi Darren,
>
> Tha
On 07/30/09 15:39, Pawel Jakub Dawidek wrote:
> On Thu, Jul 30, 2009 at 11:31:41PM +0200, Pawel Jakub Dawidek wrote:
>> On Thu, Jul 30, 2009 at 11:25:19PM +0200, Pawel Jakub Dawidek wrote:
>>> Hello.
>>>
>>> In the traverse_impl() function we can find this call:
>>>
>>> if (!(flags & TRAVERSE
On 01/23/09 16:42, Ben Rockwood wrote:
> I need some clarification on the FOID handed to zil_commit. I wrote a
> dscript to watch entry
> and return of zil_commit_writer. Here is an example output:
>
> 2009 Jan 23 23:34:36: ZIL Commit : Seq 183211310 : FOID 129644
> Completed in 0
I'll answer the ZIL question:
On 02/05/09 03:38, Ben Rockwood wrote:
> I need some help with clarification.
>
> My understanding is that there are 2 instances in which ZFS will write
> to disk:
> 1) TXG Sync
> 2) ZIL
>
> Post-snv_87 a TXG should sync out when the TXG is either over filled or
> h
On 08/22/08 10:49, Stan Park wrote:
> I'm working on doing I/O working with only the DMU and ZIL interfaces
> from the ZFS-FUSE source. I think I've got things working except for ZIL
> replays. For large writes and when slogging is not available, the itx
> write state is set to WR_INDIRECT. If I
Ricardo M. Correia wrote:
>
> On Qui, 2008-02-07 at 12:48 -0800, Matthew Ahrens wrote:
>> First, note that the problem is quite constrained:
>>
>> There are a fixed number of attribute names (for any given software version)
>> since these are interpreted system attributes. Therefore the attribu
Andreas Dilger wrote:
> On Feb 07, 2008 22:51 -0700, Neil Perrin wrote:
>>> It seems to me that the usefulness of extended attributes is to
>>> efficiently store small amounts of information associated with a file,
>>> and I think these would make more sens
On 12/07/08 09:27, Pawel Jakub Dawidek wrote:
> I can't find anything using those functions. Can they be removed?
- No. They are the vectors for reading and writing raw zvol devices
and are used in zfs_cb_ops.
Neil.
Pawel has a good point. Back in the days when UFS ruled we used to try
to have one bug fix per putback. The main reason was ease of backporting
but it also made easier understanding the webrev and the fix later;
enabling backouts, etc
Not that we always did it, but that was the goal.
The cost to t
Ricardo M. Correia wrote:
> Ricardo M. Correia wrote:
>> boolean_t need_lock = !RW_LOCK_HELD(&dp->dp_config_rwlock);
>>
>> if (need_lock)
>> rw_enter(&dp->dp_config_rwlock, RW_READER);
>>
>
> Maybe I posted to soon.
> Am I right that this specific code (in dsl_dataset.c) would work
> co
Matthew Ahrens wrote:
> Neil Perrin wrote:
>>
>> Ricardo M. Correia wrote:
>>> Ricardo M. Correia wrote:
>>>> boolean_t need_lock = !RW_LOCK_HELD(&dp->dp_config_rwlock);
>>>>
>>>> if (need_lock)
>>>> rw_ent
Chris Kirby wrote:
> Mark Maybee wrote:
>> Chris Kirby wrote:
>>
>>> Matthew Ahrens wrote:
>>>
So, we use RW_LOCK_HELD() to mean, "might this thread hold the
lock?" and it is generally only used in assertions. Eg, some
routine should only be called with the lock held, so we
>>
Chris Kirby wrote:
> Neil Perrin wrote:
>>
>> Chris Kirby wrote:
>>> But doesn't the rw_enter code block if there's a waiting
>>> writer? In other words, can't we cause a deadlock
>>> if we already hold the read lock, there'
Thanks. That would be my fault. I forgot to remove the comment.
I'll file a bug.
Neil.
Pawel Jakub Dawidek wrote On 03/15/07 10:59,:
> ZVOL was recently converted to use range locking, but it seems the
> comment below wasn't updated:
>
> /*
>* There must be no buffer changes when d
Pawel,
I don't understand the connection with the ZIL, the referenced
bug has no ZIL path. I think that deserves more investigation.
Also, please don't ship ZFS with the ZIL disabled. That would
remove POSIX compliance as fsync, O_DSYNC and friends are not
working. Applications that make use of t
I believe RW_LOCK_HELD checks it's not held by the calling thread only.
Note, a thread should not doubly read lock the same lock as
a write lock from another thread between the 2 would deadlock.
Ricardo Correia wrote On 06/01/06 22:03,:
> Hi,
>
> I think I found a bug in the rw_enter() implementa
On 12/06/09 10:11, Anurag Agarwal wrote:
> Hi,
>
> My reading of write code of ZFS (zfs_write in zfs_vnops.c), is that all
> the writes in zfs are logged in the ZIL.
Each write gets recorded in memory in case it needs to be forced out
later (eg fsync()), but is not written to the on-disk log u
17 matches
Mail list logo
