Give yourself a pat on the back :)
Kris
> Give yourself a pat on the back :)
Seconded.
--
Juha
http://www.geekzone.co.nz/juha
Pawel - you're a madman! :)
I'm afraid of what your next project will be.
Thanks for the solid work (again..),
Eric
Congratulations! You're great!
> - There is no support for booting off of ZFS file system.
Even booting kernel from a removable ufs media and then mounting a zfs
root via vfs.root.mountfrom?
--
Alex Dupre
> Is it fully 128bit? From wikipedia, which is by no means an
> authoritative source but I have no idea if this was ever an issue.
It's 64-bit even in Solaris. The "128-bitness" is only in the storage
format, not for file system ops visible to applications.
(AFAIK).
> Pawel Jakub Dawidek wrote:
>> I'm happy to inform that the ZFS file system is now part of the FreeBSD
>> operating system.
>
> Congratulations! You're great!
>
>> - There is no support for booting off of ZFS file system.
>
> Even booting kernel from a removable ufs media and then mounting a zfs root
> via vfs.root.mountfrom?
I believe the key issue here is that the boot loader doesn't yet support ZFS.
In 6.x and 7.x, the mechanism for mounting the root file system is identical
to all other file systems, so it should be possible to use any file system as
the root file system as long as you get can get the kernel up and running.
And, in the case of ZFS, the ZFS module loaded (since it currently must be a
module).
This is really exciting work and I'm very glad to see this in the tree!
Robert N M Watson
Computer Laboratory
University of Cambridge
That's correct. We are limited by POSIX, but the on-disk format is
128bit.
--
Pawel Jakub Dawidek http://www.wheel.pl
p...@FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
I'm not yet setup to move disks between FreeBSD and Solaris, but my
first goal was to integrate it with FreeBSD's GEOM framework.
We support cache flushing operations on any GEOM provider (disk,
partition, slice, anything disk-like), so bascially currently I treat
everything as a whole disk (because I simply can), but don't do any
EFI/GPT labeling. I'll try to move data from Solaris' disk to FreeBSD
and see what happen.
You are right in general, but it isn't really true for ZFS currently.
There are two very small issues:
1. Prefered way to mount ZFS file system is via 'zfs mount' command, but
it can be mounted using old way as well, so this really shouldn't be an
issue.
2. ZFS kernel module read /etc/zfs/zpool.cache file on load by accessing
it via file system. We would need to change it to load this file via
loader. Shouldn't be hard.
First try:
GEOM: ad6: corrupt or invalid GPT detected.
GEOM: ad6: GPT rejected -- may not be recoverable.
:)
this is incredibly great! thnx..
do you have any benchmark numbers? I saw some in your *con paper
but since then we got new sx locks and you did some performance
improvements as well..
I am just curious :)
thnx again!
roman
Actually, you might want to run that statement by a certain John Birrell
(j...@FreeBSD.org) regarding the DTrace port and see what answer you get.
Ceri
--
That must be wonderful! I don't understand it at all.
-- Moliere
I just verified that this will be possible:
# mount
tank on / (zfs, local)
devfs on /dev (devfs, local)
but I need some time to implement it right.
Regards,
Gabor
> Missing functionality.
>
> - There is no support for ACLs and extended attributes.
>
Is this planned ? Does that means I cannot use it as a basis for a
full-featured samba share ?
Thanks for your great work !!
Bruno DAMOUR
It is planned, but it's not trivial. Does samba support NFSv4-style
ACLs?
I got a kmem panic just by copying a recent ports.tgz (36M) onto a ZFS.
My sandbox just has 128MB RAM so kmem was set to ~40M.
After raising kmem to 80M it survived copying the file, but paniced
again while tar -xvzf the file into the same pool.
vfs.zfs.vdev.cache.size is unchanged at 10M.
--
B.Walter http://www.bwct.de http://www.fizon.de
be...@bwct.de in...@bwct.de sup...@fizon.de
I waited months for current ZFS implementation, I can wait more for root
support, now that I know it'll be possible :-) Thanks again.
I see you posted a quick start ... I will have
to move my laptop to use this as its non-root fs's :-D
R
Pawel Jakub Dawidek wrote:
> Hi.
>
> I'm happy to inform that the ZFS file system is now part of the FreeBSD
> operating system. ZFS is available in the HEAD branch and will be
> available in FreeBSD 7.0-RELEASE as an experimental feature.
>
> Commit log:
>
> Please welcome ZFS - The last word in file systems.
>
> ZFS file system was ported from OpenSolaris operating system. The code
> in under CDDL license.
>
> I'd like to thank all SUN developers that created this great piece of
> software.
>
> Supported by: Wheel LTD (http://www.wheel.pl/)
> Supported by: The FreeBSD Foundation (http://www.freebsdfoundation.org/)
> Supported by: Sentex (http://www.sentex.net/)
>
> Limitations.
>
> Currently ZFS is only compiled as kernel module and is only available
> for i386 architecture. Amd64 should be available very soon, the other
> archs will come later, as we implement needed atomic operations.
>
> Missing functionality.
>
> - We don't have iSCSI target daemon in the tree, so sharing ZVOLs via
> iSCSI is also not supported at this point. This should be fixed in
> the future, we may also add support for sharing ZVOLs over ggate.
> - There is no support for ACLs and extended attributes.
> - There is no support for booting off of ZFS file system.
>
> Other than that, ZFS should be fully-functional.
>
> Enjoy!
>
--
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)
That leads me to one question though: Why is *BSD able to bring it into
the OS as where Linux has licensing problems with the CDDL? AFAIK Linux
users can only run it in userland mode and not in kernel mode because of
the licenses.
I don't really know the differences between all the licenses, so feel
free to correct me if I'm saying something stupid.
Thanks,
Jorn
Thanks for working on it Pawel!
We're now all waiting for 7.0-RELEASE :-)
--
Florent Thoumie
f...@FreeBSD.org
FreeBSD Committer
128MB RAM of suggested minimum in ZFS requirements, but it may be not
enough... Minimum of ARC is set to 1/8 of all memory or 64MB (whichever
is more). Could you locate these lines in
sys/contrib/opensolaris/uts/common/fs/zfs/arc.c file:
/* set min cache to 1/32 of all memory, or 64MB, whichever is more */
arc_c_min = MAX(arc_c / 4, 64<<20);
Change 64 to eg. 32, recompile and retest?
My guess(!) is that they do not want non-GPL-ed code in the standard kernel.
--
Wilko Bulte wi...@FreeBSD.org
Pawel Jakub Dawidek wrote:
> On Sat, Apr 07, 2007 at 04:56:45AM +0200, Bernd Walter wrote:
>> My sandbox just has 128MB RAM so kmem was set to ~40M.
>> After raising kmem to 80M it survived copying the file, but paniced
>> again while tar -xvzf the file into the same pool.
>> vfs.zfs.vdev.cache.size is unchanged at 10M.
>
> 128MB RAM of suggested minimum in ZFS requirements, but it may be not
> enough... Minimum of ARC is set to 1/8 of all memory or 64MB (whichever
> is more). Could you locate these lines in
> sys/contrib/opensolaris/uts/common/fs/zfs/arc.c file:
>
> /* set min cache to 1/32 of all memory, or 64MB, whichever is more */
> arc_c_min = MAX(arc_c / 4, 64<<20);
>
> Change 64 to eg. 32, recompile and retest?
>
Hi Pawel,
i had the same problems like Bernd while trying to copy the src tree to
a ZFS volume. I have 384MB RAM but i got the same "kmem_map: too small"
panic. I compiled my kernel like you proposed and now i am able to copy
anything to the volume without panic :-)
Regards,
Florian
P.S. Thanks for all the work on ZFS!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
iD8DBQFGF6OmA+1tjUZ1YScRAnSMAJ4y27u0nGu9L4RgDBclxKh5q6Z/RgCgjbi7
1Ri2CZfH8YKqj8Bdmx7bedM=
=PUsh
-----END PGP SIGNATURE-----
Now with 240M kmem it looks good, but I'm still unshure:
kstat.zfs.misc.arcstats.c_min: 67108864
kstat.zfs.misc.arcstats.c_max: 188743680
kstat.zfs.misc.arcstats.size: 87653376
c_max seemed to be increasing with kmem, but I did compare it with a
remebered value.
Should be good with:
vm.kmem_size: 251658240
But top shows wired memory which is roughly twice the size of
arcstats.size, so I'm still worried about kmem exhaustion if ARC runs
up to c_max.
Since the c_min/c_max values also influence the available RAM for other
purposes as well, can we have it at least a loader.conf tuneable?
Otherwise - the reboot after the panics where impressive.
No long fsck times or noticed data corruption - even with NFS clients.
All in all it is a great job.
Just committed a change. You can tune max and min ARC size via
vfs.zfs.arc_max and vfs.zfs.arc_min tunnables.
ZFS is now also available on pc98 and amd64.
DES
--
Dag-Erling Smørgrav - d...@des.no
Great to read - is it just atomic.S missing for the remaining
architectures?
Yes. Ideally, ZFS would use FreeBSD's atomic operations instead of
its own. I believe that the reason it doesn't is (at least in part)
that we don't have 64-bit atomic operations for i386. I have
unfinished patches for cleaning up the atomic operations on all
platforms; I'll dust them off and see what I can do.
DES
--
Dag-Erling Smørgrav - d...@des.no