Pawel Jakub Dawidek
2006-Aug-22 10:45 UTC
[zfs-discuss] Porting ZFS file system to FreeBSD.
Hi.
I started porting the ZFS file system to the FreeBSD operating system.
There is a lot to do, but I''m making good progress, I think.
I''m doing my work in those directories:
contrib/opensolaris/ - userland files taken directly from
OpenSolaris (libzfs, zpool, zfs and others)
sys/contrib/opensolaris/ - kernel files taken directly from
OpenSolaris (zfs, taskq, callb and others)
compat/opensolaris/ - compatibility userland layer, so I can
reduce diffs against vendor files
sys/compat/opensolaris/ - compatibility kernel layer, so I can
reduce diffs against vendor files (kmem based on
malloc(9) and uma(9), mutexes based on our sx(9) locks,
condvars based on sx(9) locks and more)
cddl/ - FreeBSD specific makefiles for userland bits
sys/modules/zfs/ - FreeBSD specific makefile for the kernel
module
You can find all those on FreeBSD perforce server:
http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/pjd/zfs&HIDEDEL=NO
Ok, so where am I?
I ported the userland bits (libzfs, zfs and zpool). I had ztest and
libzpool compiling and working as well, but I left them behind for now
to focus on kernel bits.
I''m building in all (except 2) files into zfs.ko (kernel module).
I created new VDEV - vdev_geom, which fits to FreeBSD''s GEOM
infrastructure, so basically you can use any GEOM provider to build your
ZFS pool. VDEV_GEOM is implemented as consumers-only GEOM class.
I reimplemented ZVOL to also export storage as GEOM provider. This time
it is providers-only GEOM class.
This way one can create for example RAID-Z on top of GELI encrypted
disks or encrypt ZFS volume. The order is free.
Basically you can put UFS on ZFS volumes already and it behaves really
stable even under heavy load.
Currently I''m working on file system bits (ZPL), which is the most hard
part of the entire ZFS port, because it talks to one of the most complex
part of the FreeBSD kernel - VFS.
I can already mount ZFS-created file systems (with ''zfs
create''
command), create files/directories, change permissions/owner/etc., list
directories content, and perform few other minor operation.
Some "screenshots":
lcf:root:~# uname -a
FreeBSD lcf 7.0-CURRENT FreeBSD 7.0-CURRENT #74: Tue Aug 22 03:04:01 UTC 2006
root at lcf:/usr/obj/zoo/pjd/lcf/sys/LCF i386
lcf:root:~# zpool create tank raidz /dev/ad4a /dev/ad6a /dev/ad5a
lcf:root:~# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
tank 35,8G 11,7M 35,7G 0% ONLINE -
lcf:root:~# zpool status
pool: tank
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1 ONLINE 0 0 0
ad4a ONLINE 0 0 0
ad6a ONLINE 0 0 0
ad5a ONLINE 0 0 0
errors: No known data errors
lcf:root:# zfs create -V 10g tank/vol
lcf:root:# newfs /dev/zvol/tank/vol
lcf:root:# mount /dev/zvol/tank/vol /mnt/test
lcf:root:# zfs create tank/fs
lcf:root:~# mount -t zfs,ufs
tank on /tank (zfs, local)
tank/fs on /tank/fs (zfs, local)
/dev/zvol/tank/vol on /mnt/test (ufs, local)
lcf:root:~# df -ht zfs,ufs
Filesystem Size Used Avail Capacity Mounted on
tank 13G 34K 13G 0% /tank
tank/fs 13G 33K 13G 0% /tank/fs
/dev/zvol/tank/vol 9.7G 4.0K 8.9G 0% /mnt/test
lcf:root:~# mkdir /tank/fs/foo
lcf:root:~# touch /tank/fs/foo/bar
lcf:root:~# chown root:operator /tank/fs/foo /tank/fs/foo/bar
lcf:root:~# chmod 500 /tank/fs/foo
lcf:root:~# ls -ld /tank/fs/foo /tank/fs/foo/bar
dr-x------ 2 root operator 3 22 sie 05:41 /tank/fs/foo
-rw-r--r-- 1 root operator 0 22 sie 05:42 /tank/fs/foo/bar
The most important missing pieces:
- Most of the ZPL layer.
- Autoconfiguration. I need implement vdev discovery based on GEOM''s
taste
mechanism.
- .zfs/ control directory (entirely commented out for now).
And many more, but hey, this is after 10 days of work.
PS. Please contact me privately if your company would like to donate to the
ZFS effort. Even without sponsorship the work will be finished, but
your contributions will allow me to spend more time working on ZFS.
--
Pawel Jakub Dawidek http://www.wheel.pl
pjd at FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20060822/79939324/attachment.bin>
This is fantastic work! How long have you been at it? You seem a lot further on than the ZFS-Fuse project. On 22/08/06, Pawel Jakub Dawidek <pjd at freebsd.org> wrote:> Hi. > > I started porting the ZFS file system to the FreeBSD operating system. > > There is a lot to do, but I''m making good progress, I think. > > I''m doing my work in those directories: > > contrib/opensolaris/ - userland files taken directly from > OpenSolaris (libzfs, zpool, zfs and others) > > sys/contrib/opensolaris/ - kernel files taken directly from > OpenSolaris (zfs, taskq, callb and others) > > compat/opensolaris/ - compatibility userland layer, so I can > reduce diffs against vendor files > > sys/compat/opensolaris/ - compatibility kernel layer, so I can > reduce diffs against vendor files (kmem based on > malloc(9) and uma(9), mutexes based on our sx(9) locks, > condvars based on sx(9) locks and more) > > cddl/ - FreeBSD specific makefiles for userland bits > > sys/modules/zfs/ - FreeBSD specific makefile for the kernel > module > > You can find all those on FreeBSD perforce server: > > http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/pjd/zfs&HIDEDEL=NO > > Ok, so where am I? > > I ported the userland bits (libzfs, zfs and zpool). I had ztest and > libzpool compiling and working as well, but I left them behind for now > to focus on kernel bits. > > I''m building in all (except 2) files into zfs.ko (kernel module). > > I created new VDEV - vdev_geom, which fits to FreeBSD''s GEOM > infrastructure, so basically you can use any GEOM provider to build your > ZFS pool. VDEV_GEOM is implemented as consumers-only GEOM class. > > I reimplemented ZVOL to also export storage as GEOM provider. This time > it is providers-only GEOM class. > > This way one can create for example RAID-Z on top of GELI encrypted > disks or encrypt ZFS volume. The order is free. > Basically you can put UFS on ZFS volumes already and it behaves really > stable even under heavy load. > > Currently I''m working on file system bits (ZPL), which is the most hard > part of the entire ZFS port, because it talks to one of the most complex > part of the FreeBSD kernel - VFS. > > I can already mount ZFS-created file systems (with ''zfs create'' > command), create files/directories, change permissions/owner/etc., list > directories content, and perform few other minor operation. > > Some "screenshots": > > lcf:root:~# uname -a > FreeBSD lcf 7.0-CURRENT FreeBSD 7.0-CURRENT #74: Tue Aug 22 03:04:01 UTC 2006 root at lcf:/usr/obj/zoo/pjd/lcf/sys/LCF i386 > > lcf:root:~# zpool create tank raidz /dev/ad4a /dev/ad6a /dev/ad5a > > lcf:root:~# zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > tank 35,8G 11,7M 35,7G 0% ONLINE - > > lcf:root:~# zpool status > pool: tank > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad4a ONLINE 0 0 0 > ad6a ONLINE 0 0 0 > ad5a ONLINE 0 0 0 > > errors: No known data errors > > lcf:root:# zfs create -V 10g tank/vol > lcf:root:# newfs /dev/zvol/tank/vol > lcf:root:# mount /dev/zvol/tank/vol /mnt/test > > lcf:root:# zfs create tank/fs > > lcf:root:~# mount -t zfs,ufs > tank on /tank (zfs, local) > tank/fs on /tank/fs (zfs, local) > /dev/zvol/tank/vol on /mnt/test (ufs, local) > > lcf:root:~# df -ht zfs,ufs > Filesystem Size Used Avail Capacity Mounted on > tank 13G 34K 13G 0% /tank > tank/fs 13G 33K 13G 0% /tank/fs > /dev/zvol/tank/vol 9.7G 4.0K 8.9G 0% /mnt/test > > lcf:root:~# mkdir /tank/fs/foo > lcf:root:~# touch /tank/fs/foo/bar > lcf:root:~# chown root:operator /tank/fs/foo /tank/fs/foo/bar > lcf:root:~# chmod 500 /tank/fs/foo > lcf:root:~# ls -ld /tank/fs/foo /tank/fs/foo/bar > dr-x------ 2 root operator 3 22 sie 05:41 /tank/fs/foo > -rw-r--r-- 1 root operator 0 22 sie 05:42 /tank/fs/foo/bar > > The most important missing pieces: > - Most of the ZPL layer. > - Autoconfiguration. I need implement vdev discovery based on GEOM''s taste > mechanism. > - .zfs/ control directory (entirely commented out for now). > And many more, but hey, this is after 10 days of work. > > PS. Please contact me privately if your company would like to donate to the > ZFS effort. Even without sponsorship the work will be finished, but > your contributions will allow me to spend more time working on ZFS. > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd at FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! > > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > > >-- Rasputin :: Jack of All Trades - Master of Nuns http://number9.hellooperator.net/
On 8/22/06, Pawel Jakub Dawidek <pjd at freebsd.org> wrote:> I started porting the ZFS file system to the FreeBSD operating system.Mighty cool!! Please keep us posted!! raj
Pawel Jakub Dawidek
2006-Aug-22 12:26 UTC
[zfs-discuss] Porting ZFS file system to FreeBSD.
On Tue, Aug 22, 2006 at 12:22:44PM +0100, Dick Davies wrote:> This is fantastic work! > > How long have you been at it?As I said, 10 days, but this is really far from beeing finished. -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20060822/572bb1aa/attachment.bin>
Pawel Jakub Dawidek
2006-Aug-22 14:36 UTC
[zfs-discuss] Re: [fbsd] Porting ZFS file system to FreeBSD.
On Tue, Aug 22, 2006 at 04:30:44PM +0200, Jeremie Le Hen wrote:> I don''t know much about ZFS, but Sun states this is a "128 bits" > filesystem. How will you handle this in regards to the FreeBSD > kernel interface that is already struggling to be 64 bits > compliant ? (I''m stating this based on this URL [1], but maybe > it''s not fully up-to-date.)128 bits is not my goal, but I do want all the other goodies:) -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20060822/5d7395b9/attachment.bin>
Michael Schuster - Sun Microsystems
2006-Aug-22 14:42 UTC
[zfs-discuss] Re: [fbsd] Porting ZFS file system to FreeBSD.
Pawel Jakub Dawidek wrote:> On Tue, Aug 22, 2006 at 04:30:44PM +0200, Jeremie Le Hen wrote: >> I don''t know much about ZFS, but Sun states this is a "128 bits" >> filesystem. How will you handle this in regards to the FreeBSD >> kernel interface that is already struggling to be 64 bits >> compliant ? (I''m stating this based on this URL [1], but maybe >> it''s not fully up-to-date.) > > 128 bits is not my goal, but I do want all the other goodies:)are you going to attempt on-disk compatibility? Michael -- Michael Schuster +49 89 46008-2974 / x62974 visit the online support center: http://www.sun.com/osc/ Recursion, n.: see ''Recursion''
Eric Schrock
2006-Aug-22 15:11 UTC
[zfs-discuss] Re: [fbsd] Porting ZFS file system to FreeBSD.
On Tue, Aug 22, 2006 at 04:42:57PM +0200, Michael Schuster - Sun Microsystems wrote:> Pawel Jakub Dawidek wrote: > >On Tue, Aug 22, 2006 at 04:30:44PM +0200, Jeremie Le Hen wrote: > >>I don''t know much about ZFS, but Sun states this is a "128 bits" > >>filesystem. How will you handle this in regards to the FreeBSD > >>kernel interface that is already struggling to be 64 bits > >>compliant ? (I''m stating this based on this URL [1], but maybe > >>it''s not fully up-to-date.) > > > >128 bits is not my goal, but I do want all the other goodies:) > > are you going to attempt on-disk compatibility?Please note that the ''128-bitness'' of ZFS currently only comes into play in the on-disk format, and the allowed size of the storage pool. This should be very easy to maintain compatability with. However, each filesystem is currently limited to 64-bits, due largely to the lack of 128-bit support in the POSIX interfaces. So there''s very little 128-bit code floating around except at the SPA layer, and as long as you have an unsigned 64-bit type there shouldn''t be any problems at higher layers. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
Mark Maybee
2006-Aug-22 16:02 UTC
[zfs-discuss] Re: [fbsd] Porting ZFS file system to FreeBSD.
Michael Schuster - Sun Microsystems wrote:> Pawel Jakub Dawidek wrote: > >> On Tue, Aug 22, 2006 at 04:30:44PM +0200, Jeremie Le Hen wrote: >> >>> I don''t know much about ZFS, but Sun states this is a "128 bits" >>> filesystem. How will you handle this in regards to the FreeBSD >>> kernel interface that is already struggling to be 64 bits >>> compliant ? (I''m stating this based on this URL [1], but maybe >>> it''s not fully up-to-date.) >> >> >> 128 bits is not my goal, but I do want all the other goodies:) > > > are you going to attempt on-disk compatibility? > > MichaelAmazing work Pawel! Please do try to maintain on-disk compatibility! Let us know if you run into anything that might prevent that (or any other issues that you run across). -Mark
Wow, congratulations, nice work! I''m the one porting ZFS to FUSE and seeing you doing such progress so fast is very very encouraging :)
Ricardo Correia wrote:> Wow, congratulations, nice work! > > I''m the one porting ZFS to FUSE and seeing you doing such progress so fast is > very very encouraging :) >I''d like to throw a "me too" into the pile of thank-you messages! I spent part of the weekend expanding and manipulating a set of LVM volumes on a pair of RHEL4-ish Linux servers... And I kept grumbling to myself "if this were ZFS, I could be done by now!" Not only that, but I could have matched the configuration to the needs of the users more closely. [0] I look forward to ZFS on both Linux and FreeBSD. It will be a powerful addition to both platforms! Thanks, -Luke [0] Changing a production server from an RHEL4 clone to Solaris isn''t something that I''m likely to just-do in a couple of hours over the weekend on a cross-platform domain where I''m just assisting. If I were the sysadmin there, though, it would be practical. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3271 bytes Desc: S/MIME Cryptographic Signature URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20060823/c3e5058d/attachment.bin>
Pawel Jakub Dawidek
2006-Sep-05 08:49 UTC
[zfs-discuss] Re: Porting ZFS file system to FreeBSD.
On Tue, Aug 22, 2006 at 12:45:16PM +0200, Pawel Jakub Dawidek wrote:> Hi. > > I started porting the ZFS file system to the FreeBSD operating system.[...] Just a quick note about progress in my work. I needed slow down a bit, but: All file system operations seems to work. The only exception are operations needed for mmap(2) to work. Bascially file system works quite stable even under heavy load. I''ve problem with two assertions I''m hitting when running some heavy regression tests. I''ve spend a couple of days fighting with snapshots. To be able to implement them I needed to port GFS from Solaris (Generic pseudo-filesystem). Now, snapshots (and clones) seems to work just fine. Some other minor bits like zpool import/export, etc. now also work. File system is not yet marked as MPSAFE (it still operates under the Giant lock). -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20060905/d7ba1f60/attachment.bin>
Pawel Jakub Dawidek
2006-Sep-05 08:54 UTC
[zfs-discuss] Re: Porting ZFS file system to FreeBSD.
On Tue, Sep 05, 2006 at 10:49:11AM +0200, Pawel Jakub Dawidek wrote:> On Tue, Aug 22, 2006 at 12:45:16PM +0200, Pawel Jakub Dawidek wrote: > > Hi. > > > > I started porting the ZFS file system to the FreeBSD operating system. > [...] > > Just a quick note about progress in my work. I needed slow down a bit, > but: > > All file system operations seems to work. The only exception are > operations needed for mmap(2) to work. Bascially file system works quite > stable even under heavy load. I''ve problem with two assertions I''m > hitting when running some heavy regression tests. > > I''ve spend a couple of days fighting with snapshots. To be able to > implement them I needed to port GFS from Solaris (Generic > pseudo-filesystem). Now, snapshots (and clones) seems to work just fine. > > Some other minor bits like zpool import/export, etc. now also work. > > File system is not yet marked as MPSAFE (it still operates under the > Giant lock).And one more very important thing! The code is not yet ready for testing by others, so please don''t ask for patches. When the code will be ready I''ll publish them. -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20060905/65f437e3/attachment.bin>
Pawel Jakub Dawidek
2006-Oct-27 03:41 UTC
[zfs-discuss] Re: Porting ZFS file system to FreeBSD.
On Tue, Sep 05, 2006 at 10:49:11AM +0200, Pawel Jakub Dawidek wrote:> On Tue, Aug 22, 2006 at 12:45:16PM +0200, Pawel Jakub Dawidek wrote: > > Hi. > > > > I started porting the ZFS file system to the FreeBSD operating system. > [...] > > Just a quick note about progress in my work. I needed slow down a bit, > but:Here is another update: After way too much time spend on fighting the buffer cache I finally made mmap(2)ed reads/writes to work and (which is also very important) keep regular reads/writes working. Now I''m able to build FreeBSD''s kernel and userland with both sources and objects placed on ZFS file system. I also tried to crash it with fsx, fsstress and postmark, but no luck, it works stable. On the other hand I''m quite sure there are many problems in ZPL still, but fixing mmap(2) allows me to move forward. As a said note - ZVOL seems to be full functional. I need to find a way to test ZIL, so if you guys at SUN have some ZIL tests like uncleanly stopped file system, which at mount time will exercise entire ZIL functionality where we can verify that my FS was fixed properly that would be great. PS. There is still a lot to do, so please, don''t ask me for patches yet. -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20061027/4028c2d1/attachment.bin>
Congrats, Pawel. This is truly an impressive piece of work. As you''re probably aware, Noel integrated the patches your provided us into build 51. Hopefully that got rid of some spurious differences between the code bases. We do have a program called ''ziltest'' that Neil can probably provide for you that does a good job stressing the ZIL. We also have a complete test suite (functional and stress), but it would be non-trivial to port, and I don''t know what the current status is for open sourcing the test suites in general. Let us know if there''s anything else we can help with. - Eric On Fri, Oct 27, 2006 at 05:41:49AM +0200, Pawel Jakub Dawidek wrote:> > Here is another update: > > After way too much time spend on fighting the buffer cache I finally > made mmap(2)ed reads/writes to work and (which is also very important) > keep regular reads/writes working. > > Now I''m able to build FreeBSD''s kernel and userland with both sources > and objects placed on ZFS file system. > > I also tried to crash it with fsx, fsstress and postmark, but no luck, > it works stable. > > On the other hand I''m quite sure there are many problems in ZPL still, > but fixing mmap(2) allows me to move forward. > > As a said note - ZVOL seems to be full functional. > > I need to find a way to test ZIL, so if you guys at SUN have some ZIL > tests like uncleanly stopped file system, which at mount time will > exercise entire ZIL functionality where we can verify that my FS was > fixed properly that would be great. > > PS. There is still a lot to do, so please, don''t ask me for patches yet. > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd at FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am!-- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
Pawel, I second that praise. Well done! Attached is a copy of ziltest. You will have to adapt this a bit to your environment. In particular it uses bringover to pull a subtree of our source and then builds and later runs it. This tends to create a fair number of transactions with various dependencies. You''ll obviously have to update the paths and tools. However, at least initially, I''d recommend you simplify things by perhaps jhaving the only test as a creation of a file. The basic flow behind ziltest is: 1. Create an empty file system FS1 2. Freeze FS1 3. Perform various user commands that create files, directories, etc 4. Copy FS1 to FS2 5. Unmount and unfreeze FS1 6. Remount FS1 (resulting in replay of log) 7. Compare FS1 & FS2 and complain if not equal Hope this helps and good luck: Neil. Eric Schrock wrote On 10/27/06 10:18,:> Congrats, Pawel. This is truly an impressive piece of work. As you''re > probably aware, Noel integrated the patches your provided us into build > 51. Hopefully that got rid of some spurious differences between the > code bases. > > We do have a program called ''ziltest'' that Neil can probably provide for > you that does a good job stressing the ZIL. We also have a complete > test suite (functional and stress), but it would be non-trivial to port, > and I don''t know what the current status is for open sourcing the test > suites in general. > > Let us know if there''s anything else we can help with. > > - Eric > > On Fri, Oct 27, 2006 at 05:41:49AM +0200, Pawel Jakub Dawidek wrote: > >>Here is another update: >> >>After way too much time spend on fighting the buffer cache I finally >>made mmap(2)ed reads/writes to work and (which is also very important) >>keep regular reads/writes working. >> >>Now I''m able to build FreeBSD''s kernel and userland with both sources >>and objects placed on ZFS file system. >> >>I also tried to crash it with fsx, fsstress and postmark, but no luck, >>it works stable. >> >>On the other hand I''m quite sure there are many problems in ZPL still, >>but fixing mmap(2) allows me to move forward. >> >>As a said note - ZVOL seems to be full functional. >> >>I need to find a way to test ZIL, so if you guys at SUN have some ZIL >>tests like uncleanly stopped file system, which at mount time will >>exercise entire ZIL functionality where we can verify that my FS was >>fixed properly that would be great. >> >>PS. There is still a lot to do, so please, don''t ask me for patches yet. >> >>-- >>Pawel Jakub Dawidek http://www.wheel.pl >>pjd at FreeBSD.org http://www.FreeBSD.org >>FreeBSD committer Am I Evil? Yes, I Am! > > > -- > Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss-------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ziltest URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20061027/d1bf78ce/attachment.ksh>