Marc Moreau wrote:
> * This comment is noted from reading
> *
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/arc.c
> * which may or may not be the current version.
>
> I was reading through the code and I noticed that arc_no_grow and arc_dead
> are declared as
* This comment is noted from reading
*
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/arc.c
* which may or may not be the current version.
I was reading through the code and I noticed that arc_no_grow and arc_dead are
declared as 'int'. Looking around, they are
Jeremy Archer wrote:
> I started to look at ref counting to convince myself that the db_bu field in
> a cached dmu_impl_t object
> is guaranteed to point at a valid arc_buf_t.
>
> I have seen a "deadbeef" crash on a busy system when zfs_write() is
> pre-pagefaulting in
> the file's pages.
>
Hello,
Thanks for replying.
I am merely talking about explicitly assigning 0 or NULL to fields of a
structure,
right after is was allocated. The structure was zero filled already in its
kmem_cache_alloc* constructor.
I believe these assignments are not necessary on any OS. Am I missing
s
It appears that during the boot process, major 256 is referred to as zvol,
sometime during the boot process, it switches to the entry in
/etc/name_to_major which refers to major 256 as zfs.
Wouldn't it be better to use a consistent naming convention from boot to
multi-user run levels?
I ran in
