similar to: Recover data from detached ZFS mirror

Hi. I gave a talk about ZFS during EuroBSDCon 2007, and because it won the the best talk award and some find it funny, here it is: http://youtube.com/watch?v=o3TGM0T1CvE a bit better version is here: http://people.freebsd.org/~pjd/misc/zfs/zfs-man.swf BTW. Inspired by ZFS demos from OpenSolaris page I created few demos of ZFS on FreeBSD:

Hi. I experimented a bit with collecting entropy from the time it takes for device_attach() to run (in CPU cycles). It seems that those times have enough variation that we can use it for entropy harvesting. It happens even before root is mounted, so pretty early. On the machine I'm testing it, which has minimal kernel plus NIC driver I see 75 device_attach() calls. I'm being very careful

Hi. Here you can find patches with changes to gmirror(8) and graid3(8): http://people.freebsd.org/~pjd/patches/gmirror.7.patch http://people.freebsd.org/~pjd/patches/graid3.patch The patches does the following: - Significant synchronization speed improvement. Now many parallel synchronization I/O requests can be used instead of only one before. Many people requested this. - Close race

Hi. I have a series of patches to sandbox dhclient using Capsicum (capability mode and capability rights for descriptors). As usual, because chroot and setgid/setuid are not sandboxing mechanisms, there are many problems with the current sandboxing: - Access to various global namespaces (like process list, network, etc.). - Access to RAW UDP socket. - Read/write access to bpf. - Access to RAW

The time has come to review the current Contributor and Core contributor grants for ZFS. Since all of the ZFS core contributors grants are set to expire on 02-24-2009 we need to renew the members that are still contributing at core contributor levels. We should also add some new members to both Contributor and Core contributor levels. First the current list of Core contributors: Bill

Hello, I think there was already a thread on this. I just want to raise the question again if anyone has successfully booted an gdbe-encrypted filesystem (everything encrypted except the bootloader). The passphrase is entered at the bootloader prompt or embedded in the bootloader. I appreciate any tips. Thanks, - ronnel

Hi. I've no response from so@ in this topic, probably because leak of time, so I'll try here. Here is a patch that I'm planing to commit: http://people.freebsd.org/~pjd/patches/restricted_hardlinks.patch It adds two new sysctls: security.bsd.hardlink_check_uid security.bsd.hardlink_check_gid If sysctl security.bsd.hardlink_check_uid is set to 1, unprivileged users are not

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

I got roughly the same performance results when I use the openssl speed test with and without a hifn 7956 cryto card Here's what I did: After the card is plugged in, kldload hifn; kldload cryptodev; I got the message: hifn0 mem 0xfc8f0000-0xfc8f7ffff, 0xfc8f0000-0xfc8f7ffff, 0xfc8f0000-0xfc8f7ffff irg 28 at device 3.0 on pci1 hifn0: Hifn 7956, rev 0, 32KB dram, pll=0x800<pci clk, 4x

Hi. I noticed that when non-64bit variable is given as a second argument to atomic_add_64() function, the result is invalid. I found few places where such situation occurs. I wonder how this got unnoticed with ztest, which fails on me within a few seconds (after I started to use Solaris atomic operations) on assertions. Maybe this only doesn''t work when compiled with gcc? Not sure, but

Hi. We''re testing the most recent ZFS version from OpenSolaris ported to FreeBSD. Kris (CCed) observed strange situation. In function arc_read() he had a panic on assertion that we try to unlock a lock which is not beeing held: rw_enter(&pbuf->b_hdr->b_datalock, RW_READER); err = arc_read_nolock(pio, spa, bp, done, private, priority, flags, arc_flags, zb);

Hi. When we don't have too many IP addresses available and we want to run for example www server inside a jail, but use the same IP address as the main system, we need to actually use an internal IP address and forward http port with firewall from external IP to jail's IP. In that way we know that if somebody breaks into out jail, he cannot run sshd server (we have keys, I know) or any

ZFS works really stable on FreeBSD, but I''m biggest problem is how to control ZFS memory usage. I''ve no idea how to leash that beast. FreeBSD has a backpresure mechanism. I can register my function so it will be called when there are memory problems, which I do. I using it for ARC layer. Even with this in place under heavy load the kernel panics, because memory with KM_SLEEP

Hi. I'd like to commit this patch: http://people.freebsd.org/~pjd/patches/vfs_mount.c.9.patch It currently should change nothing, but will be needed once we allow to grant privileges for jails. I'd like to commit it now, so I can experiment easier with my ZFS improvements. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org

Hi. I've been playing a bit with "use sound card as an entropy source" idea. This simple program does what I wanted: http://people.freebsd.org/~pjd/misc/sndrand.tbz The program is very simple, it should be run with two arguments: % sndtest /dev/dspW 1048576 > rand.data This command will generate 1MB of random data. With my sound card: pcm0: <Intel ICH3 (82801CA)>

Yeah:) I''d like to work on this. Here are my first observations: - We need to call vdev_op_asize method with additonal ''offset'' argument, - We need to move data to new disk starting from the very begining, so we can''t reuse scrub/resilver code which does tree-walk through the data. Below you can see how I imagine to extend RAIDZ. Here is the legend:

Hi. I''ve almost all file system functions working. I started to run some heavy file system regression tests. They work. fsx wasn''t able to break my port, but the test you can find here: http://people.freebsd.org/~kan/fsstress.tar.gz broke it. My kernel panics on this assertion (zfs_dir.c): 749: mutex_exit(&dzp->z_lock); 750: 751: error =

I''m CCing zfs-discuss at opensolaris.org, as this doesn''t look like FreeBSD-specific problem. It looks there is a problem with block allocation(?) when we are near quota limit. tank/foo dataset has quota set to 10m: Without quota: FreeBSD: # dd if=/dev/zero of=/tank/test bs=512 count=20480 time: 0.7s Solaris: # dd if=/dev/zero of=/tank/test bs=512 count=20480 time: 4.5s

Tuning should not be done in general and Best practices should be followed. So get very much acquainted with this first : http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide Then if you must, this could soothe or sting : http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide So drive carefully. -r

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-07:01.jail Security Advisory The FreeBSD Project Topic: Jail rc.d script privilege escalation Category: core Module: etc_rc.d Announced: