So first of all, we're not proposing dumping to a filesystem.
We're proposing dumping to a zvol, which is a raw volume
implemented within a pool (see the -V option to the zfs
create command). As Malachi points out, the advantage
of this is that it simplifies the ongoing administration. You don't
have to have pre-allocate a slice of the appropriate size, and
then be unable to grow the space later.
You are right that at crash dump time, you want as little
complexity as possible in the process of writing out the dump
because there's no knowing how broken the system is.
So consider what happens with dump files and UFS. With
UFS, you can set up a file as a dump device. This is not as
crazy as it sounds because at the time you set up the dump
device (through dumpadm), UFS allocates the space and
sets up an array of offset-length pointers to the space, so
that at the time the crash dump takes place, some really
dumb code in the kernel just has to run that list and hose
the memory contents into those pre-allocated areas on the
disk. We are looking at doing something similar with zfs,
where the space is allocated and pointers to it prepared in
advance, so that at crash time, we only need very simple
code to write out the dump.
I'm not in charge of the zfs dump development, so I don't
know the technical details, but I think that the development
is proceeding along these lines.
Lori
Brian Gupta wrote:
Please bear with me, as I am not very familiar with ZFS. (And
unfortunately probably won't have time to be until ZFS supports root
boot and clustering in a named release).
I do understand the reasons why you would want to dump to a virtual
construct. I am just not very comfortable with the concept.
My instinct is that you want the fewest layers of software involved in
the event of a system crashdump.
To me dumping to logical volumes or filesystems seems like asking for
trouble. Now on the other hand, if you were to dump to an underlying
"zdev" it starts to make sense. (Assuming a zdev is basically a
physical "chunk" of a LUN or disk.
Please educate me as to what I am missing.
Thanks,
Brian
On 4/25/07, Malachi de Ælfweald <[EMAIL PROTECTED]> wrote:
Maybe so that it can grow rather than being tied to a specific piece of
hardware?
Malachi
On 4/25/07, Brian Gupta < [EMAIL PROTECTED]> wrote:
>
> > Yes, dump on ZVOL isn't currently supported, so a dump slice is
still
needed.
>
> Maybe a dumb question, but why would anyone ever want to dump to an
> actual filesystem? (Or is my head thinking too Solaris)
>
> Actually I could see why, but I don't think it is a good idea.
>
> -brian
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
