[zfs-code] Bug 6678070 reported also on FreeBSD/ZFS.

... Mark, do you work on a fix currently? Or maybe you guys have any suggestion where to go from here? -- Pawel Jakub Dawidek http://www.wheelsystems.com pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I

[zfs-code] zvol_minor_lookup() possible problem.

zvol will be returned no matter if the name matches or not. Simple patch to correct that is here: http://people.freebsd.org/~pjd/patches/zvol.c.2.patch -- Pawel Jakub Dawidek http://www.wheelsystems.com pjd at FreeBSD.org http://www.F

[zfs-code] mze_insert() panic (avl_find() succeeded inside avl_add())

On Wed, Sep 09, 2009 at 03:13:27PM -0700, Matthew Ahrens wrote: > Pawel Jakub Dawidek wrote: > >On Wed, Sep 09, 2009 at 10:07:08AM -0700, Matthew Ahrens wrote: > >>Unfortunately, I don't think that the send stream would help us diagnose > >>it further. What we r

[zfs-code] mze_insert() panic (avl_find() succeeded inside avl_add())

rent are inodes - those duplicates have different inode number that the ones I removed. -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -

[zfs-code] mze_insert() panic (avl_find() succeeded inside avl_add())

On Wed, Sep 09, 2009 at 03:25:58PM +0400, Dmitry Morozovsky wrote: > On Wed, 9 Sep 2009, Pawel Jakub Dawidek wrote: > > PJD> > If there is ZFS developer interested in tracking it further down, > maybe Dmitry > PJD> > will be able to provide snapshot of this corrupted

[zfs-code] mze_insert() panic (avl_find() succeeded inside avl_add())

On Wed, Sep 09, 2009 at 12:18:53PM +0200, Pawel Jakub Dawidek wrote: > Hi. > > There is a bug (6709336), which was closed with 'Not Reproducible' reason, but > I've a file system over here, where it is easy to reproduce. Dmitry (fs > owner) > send me a snapshot

[zfs-code] mze_insert() panic (avl_find() succeeded inside avl_add())

ng it further down, maybe Dmitry will be able to provide snapshot of this corrupted file system. -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am!

[zfs-code] dnode_cons() is called twice.

On Sat, Sep 05, 2009 at 03:22:12PM +0200, Ricardo M. Correia wrote: > On Sat, 2009-09-05 at 15:08 +0200, Pawel Jakub Dawidek wrote: > > > Unfortunately your fix will not work correctly, because the DMU code > > > expects all of the dnode_t fields to be initialized to 0 a

[zfs-code] dnode_cons() is called twice.

eview, not from the > Lustre team nor from the ZFS team. It seems to be working reasonably for > us in our very limited testing, but use at your own risk :-) > > I am planning to do a code review of this patch and integrate it into > Nevada some time in the future, along with

[zfs-code] dnode_cons() is called twice.

6,7 +276,6 @@ uint64_t object) { dnode_t *dn = kmem_cache_alloc(dnode_cache, KM_SLEEP); - (void) dnode_cons(dn, NULL, 0); /* XXX */ dn->dn_objset = os; dn->dn_object = object; -- Pawel Jakub Dawidek http://www.wheel.pl pj

[zfs-code] Argument allocated on stack passed to taskq.

On Thu, Jul 30, 2009 at 11:31:41PM +0200, Pawel Jakub Dawidek wrote: > On Thu, Jul 30, 2009 at 11:25:19PM +0200, Pawel Jakub Dawidek wrote: > > Hello. > > > > In the traverse_impl() function we can find this call: > > > > if (!(flags & TRAVERSE_PREFETC

[zfs-code] Argument allocated on stack passed to taskq.

On Thu, Jul 30, 2009 at 11:25:19PM +0200, Pawel Jakub Dawidek wrote: > Hello. > > In the traverse_impl() function we can find this call: > > if (!(flags & TRAVERSE_PREFETCH) || > 0 == taskq_dispatch(system_taskq, traverse_prefetch_thread, >

[zfs-code] Argument allocated on stack passed to taskq.

h_thread() function with td argument from a separate thread. This doesn't look safe, as td is allocated on the stack at the begining of traverse_impl() and won't be accessible from taskq thread. Is my understanding correct? -- Pawel Jakub Dawidek http://www.wheel.pl

[zfs-code] PSARC/2009/204 ZFS user/group quotas & space accounting

On Tue, Apr 21, 2009 at 10:04:53AM -0600, Matthew Ahrens wrote: > Mark Maybee wrote: > >Pawel Jakub Dawidek wrote: > >>On Sat, Apr 18, 2009 at 06:05:56PM -0700, Matthew.Ahrens at sun.com wrote: > >>>Author: Matthew Ahrens > >>>Repositor

[zfs-code] PSARC/2009/204 ZFS user/group quotas & space accounting

SD, because we don't have Python in base system. > 6827260 assertion failed in arc_read(): hdr == pbuf->b_hdr I see this assertion beeing removed from arc.c, can you give more details on how the actual bug causing this assertion was fixed? (We were seeing this pani

[zfs-code] new RAID algorithms

ools with raid5/raid6 vdevs should work. The patch is also against some old version of ZFS, but might be a good starting point for you: http://people.freebsd.org/~pjd/patches/vdev_raid5.patch Good luck. -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD

[zfs-code] 6551866 deadlock between zfs_write(), zfs_freesp(), and zfs_putapage()

pdate: usr/src/uts/common/fs/zfs/zfs_znode.c I think after this commit, the comment above update_pages() is no longer true: * On Write:If we find a memory mapped page, we write to *both* * the page and the dmu buffer. -- Pawel Jakub Dawidek http:

[zfs-code] zvol_read() and zvol_write().

On Sun, Dec 07, 2008 at 09:32:57AM -0700, Neil Perrin wrote: > On 12/07/08 09:27, Pawel Jakub Dawidek wrote: > >I can't find anything using those functions. Can they be removed? > > - No. They are the vectors for reading and writing raw zvol devices > and are used in zfs_

[zfs-code] zvol_read() and zvol_write().

I can't find anything using those functions. Can they be removed? -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -- next

[zfs-code] Inuse cache devices.

disk. # zpool create tank1 da0 cache da1 # zpool export tank1 # zpool create tank2 da2 cache da1 It doesn't complain that da1 is used in exported pool tank1. -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.F

[zfs-code] truncate(2) not working properly.

On Sat, Aug 16, 2008 at 08:33:53AM -0600, Mark Maybee wrote: > This fix for this bug is currently in test and will be pushed shortly. Good to hear that, thanks! -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.

[zfs-code] truncate(2) not working properly.

On Tue, Jul 22, 2008 at 08:56:31AM -0600, Mark Shellenbaum wrote: > Pawel Jakub Dawidek wrote: > >On Tue, Jul 22, 2008 at 04:28:45PM +0200, Pawel Jakub Dawidek wrote: > >>Hi. > >> > >>I just reproduced a problem I was chasing on FreeBSD also on > >>Ope

[zfs-code] Unexpected b_hdr change.

On Tue, Jul 29, 2008 at 12:41:16PM +0200, Pawel Jakub Dawidek wrote: > 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

[zfs-code] simulating disk failures

e appreciated. > > Try using 'zinject': > # zpool create -f d mirror c0t0d0 c0t1d0 spare c7t6d0 > # zinject -d c0t0d0 d > # mkfile 20m /d/20m.txt While we are at zinject... Could you take care of the patch below: http://people.freebsd.org/~pjd/patches/zio_inject

[zfs-code] Unexpected b_hdr change.

sync+0x2f3 txg_sync_thread() at txg_sync_thread+0x2cd Do you have any ideas how to fix it? Kris has a way to reproduce it in his environment and I'm sure he could try a patch, if you could provide one. -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBS

[zfs-code] truncate(2) not working properly.

On Tue, Jul 22, 2008 at 05:06:21PM +0200, Pawel Jakub Dawidek wrote: > On Tue, Jul 22, 2008 at 08:56:31AM -0600, Mark Shellenbaum wrote: > > Pawel Jakub Dawidek wrote: > > >On Tue, Jul 22, 2008 at 04:28:45PM +0200, Pawel Jakub Dawidek wrote: > > >>Hi. > > >&g

[zfs-code] truncate(2) not working properly.

On Tue, Jul 22, 2008 at 08:56:31AM -0600, Mark Shellenbaum wrote: > Pawel Jakub Dawidek wrote: > >On Tue, Jul 22, 2008 at 04:28:45PM +0200, Pawel Jakub Dawidek wrote: > >>Hi. > >> > >>I just reproduced a problem I was chasing on FreeBSD also on > >>Ope

[zfs-code] truncate(2) not working properly.

On Tue, Jul 22, 2008 at 04:28:45PM +0200, Pawel Jakub Dawidek wrote: > Hi. > > I just reproduced a problem I was chasing on FreeBSD also on > OpenSolaris from around 2008.01. > > Simply doing something like this: > > write 9k of random data into 'foo' f

[zfs-code] truncate(2) not working properly.

;ftruncate(%d)", 11 * 1024); if (pread(fd, buf1, sizeof(buf1), 7 * 1024) != sizeof(buf1)) err(1, "pread()"); for (i = 0; i < sizeof(buf1); i++) { if (buf1[i] != '\0') errx(2, "unexpected

[zfs-code] Deadlock (l2cache).

e forever, because the previous process hangs, and spa_config_exit() is called at the end of spa_vdev_add() (via spa_vdev_exit()) and spa_config_exit() calls cv_broadcast() for this condvar. -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org

[zfs-code] Some bugs/inconsistencies.

On Sun, May 18, 2008 at 11:01:40PM +0200, Pawel Jakub Dawidek wrote: > On Sun, May 04, 2008 at 10:10:31PM +0200, Pawel Jakub Dawidek wrote: > > Hi. > > > > I'm working on getting the most recent ZFS to the FreeBSD's CVS. Because > > of the huge amount

[zfs-code] Some bugs/inconsistencies.

On Sun, May 04, 2008 at 10:10:31PM +0200, Pawel Jakub Dawidek wrote: > Hi. > > I'm working on getting the most recent ZFS to the FreeBSD's CVS. Because > of the huge amount of changes, I decided to work on ZFS regression > tests, so I'm more or less sure

[zfs-code] Some bugs/inconsistencies.

DEGRADED 0 0 0 disk1 OFFLINE 0 0 0 disk2 ONLINE 0 0 0 Note how various states changed after export/import cycle. That's all for now, hopefully nothing more to come:) -- Pawel Jakub Dawidek

[zfs-code] Small nit.

nap) - (void) strlcpy(zc.zc_value, fromsnap, sizeof (zc.zc_name)); + (void) strlcpy(zc.zc_value, fromsnap, sizeof (zc.zc_value)); zc.zc_cookie = outfd; zc.zc_obj = fromorigin; -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.

[zfs-code] Recent deadlock.

On Wed, Nov 07, 2007 at 08:57:53AM -0700, Mark Maybee wrote: > Pawel Jakub Dawidek wrote: > > On Wed, Nov 07, 2007 at 07:41:54AM -0700, Mark Maybee wrote: > >> Hmm, seems rather unlikely that these two IOs are related. Thread 1 > >> is trying to read a dnode in orde

[zfs-code] Recent deadlock.

fixes deadlock for me. > I think vdev_mirror_io_done() often shows up in the stack because the > ditto-ing code leverages that code path. Ahh, ok. -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeB

[zfs-code] Recent deadlock.

ext_stage(d11e56b4,c3b38440,f8aa2c3c,246,c0a116b4,...) at > > zio_next_stage+0x236 > > vdev_mirror_io_done(d11e56b4,f8aa2cf8,c42c94de,d11e56b4,0,...) at > > vdev_mirror_io_done+0x113 > > zio_vdev_io_done(d11e56b4,0,c43e6f2d,33d,c442ec14,...) at > > zio_vdev_io_done+0

[zfs-code] Recent deadlock.

On Mon, Nov 05, 2007 at 02:22:12PM +0100, Pawel Jakub Dawidek wrote: > Hi. > > I'm observing the following deadlock. > > One thread holds zfsvfs->z_hold_mtx[i] lock and waits for I/O: [...] > Another thread tries to finish I/O, but can't, because it is trying to

[zfs-code] z_fuid_lock

The patch below properly initialize and destroys z_fuid_lock: http://people.freebsd.org/~pjd/opensolaris/11.patch -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer

[zfs-code] Recent deadlock.

see this deadlock after last integration, so it was introduced in more or less during last month. Any ideas how to solve it? -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer

[zfs-code] Figuring out individual changes.

annot handle, it just takes more time. > Sorry if that wasn't clearer. Thanks again for contributing! Thank you for intergating my contributions, it helped a lot! I really hope that the FreeBSD community will be able to give something major back at some point.

[zfs-code] Figuring out individual changes.

Sun and export them to mercurial in bigger chunks, or this is bascially how you work now? In FreeBSD we always try to keep unrelated changes in separate commits and this is really useful. I think my question is if I can read the changes separately somehow? If the answer is no, maybe it is

[zfs-code] System call to create a clone of a file on a ZFS filesystem?

On Fri, Oct 12, 2007 at 11:10:31AM +0100, Darren J Moffat wrote: > Pawel Jakub Dawidek wrote: > > I understand it's not trivial, but beeing able to reference the same > > block from different datasets would be a really nice feature to have. > > The functionality discussed

[zfs-code] System call to create a clone of a file on a ZFS filesystem?

On Thu, Oct 11, 2007 at 09:49:51AM -0700, Matthew Ahrens wrote: > Pawel Jakub Dawidek wrote: > > On Thu, Oct 11, 2007 at 10:47:44AM +0100, Robert Milkowski wrote: > >> Hello Matthew, > >> > >> Thursday, October 11, 2007, 9:10:13 AM, you wrote: > >> >

[zfs-code] System call to create a clone of a file on a ZFS filesystem?

x27; to switch the relatioship, but you cannot make them independent, AFAIK. To Matthew: As I understand it, Robert was talking more about moving the blocks to another dataset, not creating a hardlink-like situation - only one dataset will reference the blocks after the move. -- Pawel Jakub Dawidek

[zfs-code] Extending RAIDZ.

On Wed, Sep 19, 2007 at 03:06:20PM -0700, Matthew Ahrens wrote: > Pawel Jakub Dawidek wrote: > > On Tue, Aug 07, 2007 at 11:28:31PM +0100, James Blackburn wrote: > >> Well I read this email having just written a mammoth one in the other > >> thread, my thoughts: >

[zfs-code] Extending RAIDZ.

one disk. ZFS can ask raidz vdev for a block using exactly the same offset+size as before. This should be enough, but isn't. Checksum is stored with a block pointer in a leaf vdev? If so, why? -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org

[zfs-code] Code/comment mismatch in delegated administration code.

p, VWRITE, cr, td) != 0) { + error = EPERM; goto out; } -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer

[zfs-code] ARC deadlock.

problematic: > >... > >>And second one, which holds > >>arc_buf_t->b_hdr->hash_lock: > > > > > >Bug 6457639 might be related, > >http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6457639 > > > >In this case I also found the arc deadlocking b

[zfs-code] Extending RAIDZ.

U U U U U U U U The biggest problem for me is a method to traverse allocated blocks sorted by offset. Any hints how to do it? -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeB

[zfs-code] PSARC/2006/465 ZFS Delegated Administration

ariable is not set, so we return success without mounting the file system. It's quite hard to makr VOP_GETATTR() to fail, but just for consistency... -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD co

[zfs-code] PSARC/2006/465 ZFS Delegated Administration

On Sun, Jul 08, 2007 at 05:57:25PM -0600, Mark Shellenbaum wrote: > Pawel Jakub Dawidek wrote: > >On Tue, Jun 26, 2007 at 07:45:51AM -0700, Mark.Shellenbaum at Sun.COM wrote: > >>Author: marks > >>Repository: /hg/onnv/onnv-gate > >>Latest revision: 12bb

[zfs-code] PSARC/2006/465 ZFS Delegated Administration

t; 6572465 'zpool set bootfs=...' records history as 'zfs set bootfs=...' In this commit you changed: { zfs_ioc_set_prop, zfs_secpolicy_write,dataset_name }, to: { zfs_ioc_set_prop, zfs_secpolicy_none, dataset_name, B_TRUE }, Was that intended? Is zfs_s

[zfs-code] Corrupted pools

block wasn't yet written to the disk. But until you have power, the lack of DKIOCFLUSHWRITECACHE shouldn't cause any problems. PS. In FreeBSD we use BIO_FLUSH for flushing write cache, which I implemented as a part of different project (gjournal). -- Pawel Jakub Dawide

[zfs-code] Refactor zfs_zget()

bjects. > > See the attached patch (and sorry for the mismatched paths WRT the > OpenSolaris > tree). Simple test that does open(O_CREAT)/fstat()/unlink()/fstat() seems to work fine on both FreeBSD and Solaris. Maybe your problem is somewhere else? -- Pawel Jakub Da

[zfs-code] ZFS_DIRENT_*().

On Tue, May 01, 2007 at 05:48:15PM -0700, Matthew Ahrens wrote: > Pawel Jakub Dawidek wrote: > >so I started to use it. The thing is that it broke some functionality. > >For example 'zpool status -v' doesn't show file names anymore. > >I tracked it down to

[zfs-code] mappedwrite().

() unconditionally, because if uiomove() partially succeeds, we will lose the change. If uiomove() fails entirely, well, we just write what we got before one more time. Is it also the case for OpenSolaris? -- Pawel Jakub Dawidek http://www.wheel.pl

[zfs-code] ARC deadlock.

s my description make sense? Do you have any suggestions how to fix it? -- 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

[zfs-code] Dataset Key storage

Do you have an analysis/list of things that won't be encrypted? What are the possible threats? For example will it be possible to move blocks within a pool, which won't be discovered by ZFS? -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org

[zfs-code] ZFS_DIRENT_*().

*/ type = ZFS_DIRENT_TYPE(zap.za_first_integer); Should I clear 'type' somewhere maybe or is my change to zap_value_search() correct? If the latter, can someone verify other uses of za_first_integer? -- Pawel Jakub Dawidek http://www.wheel

[zfs-code] Stale comment in zvol.c.

roach than a per zvol rwlock would be to lock * ranges. */ -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --

[zfs-code] Codereview ZFS using KCF/libmd for SHA256

ektion=9&format=html The good thing is that we probably need very simple API for 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-code] zfs_path_to_zhandle()

On Thu, Feb 22, 2007 at 08:42:35PM +0100, Pawel Jakub Dawidek wrote: > Hi. > > The zfs_path_to_zhandle() function was recently added to libzfs and I'm > trying to figure out how it works by reading the code. > > /* > * Given a name, determine whether or not it's

[zfs-code] zfs_path_to_zhandle()

e for? ZFS file systems are not based on raw device, right? What does mnt_major and mnt_minor here mean exactly? I thought that those are numbers of device from which file system is mounted. Can someone give me an example of how this code path is used? zfs list / -- Pawel Jak

[zfs-code] Improper use of atomic_add_64().

On Mon, Feb 19, 2007 at 05:15:08AM +, Ricardo Correia wrote: > On Sunday 18 February 2007 01:41, Pawel Jakub Dawidek wrote: > > 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 >

[zfs-code] Improper use of atomic_add_64().

operations) on assertions. Maybe this only doesn't work when compiled with gcc? Not sure, but most of the time 64bit variables are used properly. Anyway, the patch is here: http://people.freebsd.org/~pjd/opensolaris/10.patch -- Pawel Jakub Dawidek

[zfs-code] Request for help and advice on cache behaviour

Linux use for caching, but ARC is really nice and efficient. > PS: I'm also considering opening the vdevs (the underlying block devices or > files) with O_DIRECT, otherwise the kernel will also cache them. Does it make > sense? I'd guess it makes a lot of sense, cache duplic

[zfs-code] Small nits in zfs_fm.c.

nder if this is good place to send them or if I should send them somewhere else (I looked at bugs.opensolaris.org, but for patches I found recommendation to use request-sponsor at opensolaris.org). Thanks. -- Pawel Jakub Dawidek http://www.wheel.pl pjd

[zfs-code] More lock init/destroy.

Hi. The patch below contains more {mutex,rw,cv}_{init,destroy} cleanups: http://people.freebsd.org/~pjd/opensolaris/09.patch -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer

[zfs-code] Small nits in zfs_fm.c.

On Mon, Nov 13, 2006 at 03:14:04PM +0100, Pawel Jakub Dawidek wrote: > The patch below correct typo, duplicated entry and argument type. > (I'm not sure if duplicated entry removal is correct, as this is only > based on looking at the code.) > > http://people.freebsd.org

[zfs-code] Looking for confirmation.

On Tue, Aug 29, 2006 at 10:38:31AM -0700, Matthew Ahrens wrote: > Pawel Jakub Dawidek wrote: > >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

[zfs-code] Lock order reversal (harmless?).

On Wed, Nov 22, 2006 at 08:35:44AM -0700, Mark Maybee wrote: > Pawel Jakub Dawidek wrote: [...] > >Bascially it first recorded that db_mtx is locked before z_lock and the > >backtrace above is from where is it locked in an different order. > Um, I think you have that backwards:

[zfs-code] Lock order reversal (harmless?).

sible here, right? If I'm right, sorry for the noice, just wanted to be 100% sure. -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -

[zfs-code] Tracking opensolaris changes.

Hi. Do you have a mailing lists where information about all commits goes to? It'd be best if both commit log and diff will be send there. -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD comm

[zfs-code] ZFS and memory usage.

mory still. I'll try to investigate further. Thanks. -- 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

[zfs-code] Small nits in zfs_fm.c.

The patch below correct typo, duplicated entry and argument type. (I'm not sure if duplicated entry removal is correct, as this is only based on looking at the code.) http://people.freebsd.org/~pjd/opensolaris/08.patch -- Pawel Jakub Dawidek http://www.wheel.p

[zfs-code] ZFS and memory usage.

On Fri, Nov 10, 2006 at 06:36:07AM -0700, Mark Maybee wrote: > Pawel Jakub Dawidek wrote: > >On Tue, Nov 07, 2006 at 06:06:48PM -0700, Mark Maybee wrote: > >>The problem is that in ZFS the vnode holds onto more memory than just > >>the vnode itself. Its fine to place

[zfs-code] ZFS and memory usage.

the znode at VOP_INACTIVE() rather than waiting > until VOP_RECLAIM(). How? From What I see znode is freed via zfs_znode_free() called from znode_pageout_func(). I don't think I can just call zfs_znode_free(), as I'm quite sure there are some dependent resources I need to release. Whi

[zfs-code] ZFS and memory usage.

it's just that backpressure mechanism doesn't work too well. My function is called when there is no memory in the system, is there anything I can do from there to decrease the number of active dnodes? -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org

[zfs-code] ZFS and memory usage.

if kept around. In FreeBSD VOP_INACTIVE() means "puts the vnode onto free vnodes list" and when we want to use this vnode for different file system VOP_RECLAIM() is called and VOP_RECLAIM() will be a good place to free znode as well, if possible. Any ideas how to fix it? -- Pawel Jakub Daw

[zfs-code] Opening a snapshot.

On Sun, Aug 27, 2006 at 08:27:55AM -0600, Mark Maybee wrote: > Pawel Jakub Dawidek wrote: > > >Hi. > > > >I'm currently working on snapshots and can't understand one thing. > > > >When someone lookups a snapshot directory it gets automatically mount

[zfs-code] Opening a snapshot.

e I messed up? Any ideas? -- 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...

[zfs-code] Looking for confirmation.

On Fri, Aug 25, 2006 at 08:33:32AM -0600, Mark Shellenbaum wrote: > Pawel Jakub Dawidek wrote: > >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

[zfs-code] Looking for confirmation.

create tank ... # fsstress -d /tank/ -n 1 -p 16 This will tell me if this is mine or ZFS's insuffiecient synchronization somewhere. Thanks in advance! -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org

[zfs-code] Some ZFS patches.

, I'm not sure whether we need to treat these patches as > contributions or just bug reports. I'll ping someone more familiar with > the process to find out whether you need to agree to the Sun Contributor > Agreement at: > > http://www.opensolaris.org/os/about/sun

[zfs-code] Some ZFS patches.

On Tue, Aug 22, 2006 at 07:46:21AM +1000, James C. McPherson wrote: > Pawel Jakub Dawidek wrote: > >Hi. > >I've some ZFS patches, maybe you'd find them useful: > > http://people.freebsd.org/~pjd/opensolaris/00.patch > > http://people.freebsd.org/~

[zfs-code] Some ZFS patches.

s/03.patch http://people.freebsd.org/~pjd/opensolaris/04.patch http://people.freebsd.org/~pjd/opensolaris/05.patch http://people.freebsd.org/~pjd/opensolaris/06.patch http://people.freebsd.org/~pjd/opensolaris/07.patch -- Pawel Jakub Dawidek