On 2006-08-09, Matthew Dillon <[EMAIL PROTECTED]> wrote:
> And, poof, no more indefinite blocking states in the kernel for NFS or
> for the upcoming userland VFS or clustering.
>
> There will be fine-grained range locks to maintain UNIX atomicy
> requirements, but since they aren't
On 2006-08-07, Joerg Sonnenberger <[EMAIL PROTECTED]> wrote:
> The current UFS code is complicated, since it didn't have a separation
> between namespace locking and content locking. When you kill the whole
> relocking dance, it becomes much simpler. Noone wants to really clean
> the UFS locking th
On 2006-08-07, Matthew Dillon <[EMAIL PROTECTED]> wrote:
>
> :Well, it's OK that fvp has to be locked, but giving up when the first
> :lock attempt fails looks poor to me. Isn't it just gambling that someone
> :else won't take the lock between entering ufs_rename() and trying to
> :lock fvp?
>
>
On 2006-08-07, Matthew Dillon <[EMAIL PROTECTED]> wrote:
>:
>:if ((error = vn_lock(fvp, LK_EXCLUSIVE)) != 0)
>: goto abortit;
>
> That's pretty much how the BSD's do it, because the old filesystems
> like UFS require an atomic LOOKUP + OP (e.g. LOOKUP + CREATE,
> LO
Hi,
VOP_RENAME is a notorious beast, and, IIRC, Matt (and maybe others) has
claimed that it should be tamed. I wonder what are we to expect here...
As I see, the main issues are the following:
1) Many things has to be locked at the same time.
2) It should be checked if the target dir is not unde
On 2006-03-23, Matthew Dillon <[EMAIL PROTECTED]> wrote:
> The dump is calculated from the end of swap space backwards, based on
> physical memory. So the answer is: not easily.
Well then, my reminiscences of successfully saving the dump of a low
hw.physmem'd session come from FreeBSD. Lo
Hi,
To reduce kernel dump sizes, one can set the hw.physmem kernel env var
to a small value at boot time. However, recently I experienced that
savecore(8) fails to fetch the dump if the actually used physmem size
differs from the one used at dump time.
Could this be fixed?
Thanks,
Csaba
On 2006-02-10, Oliver Fromme <[EMAIL PROTECTED]> wrote:
> As far as "a hundredsome one line RCS id diffs" go: You
> can disable them easily in /etc/mergemaster.rc or in your
> $HOME/.mergemasterrc, so you don't have to ACK them at all.
> It also has settings to ignore /etc/motd, to specify
> addit
On 2006-02-09, Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote:
> config files (for ssh or inetd, for instance). IMO we desperately need
> a wicked tool which do the right thing[tm]. something with three-way
> merges and stuff...
While such a tool would be cool, it might take some time while
On 2006-02-09, Matthew Dillon <[EMAIL PROTECTED]> wrote:
> Our 'make upgrade' target deletes all old files that are no longer
> part of the official distribution. Its all integrated in already.
As a sidenote, I saw the refreshing lack of mergemaster from
upgrade instructions. I *loathe* t
On 2006-02-08, Matthew Dillon <[EMAIL PROTECTED]> wrote:
> The problem is not what happens after you lock the group, the problem
> is the locking operation itself.
>
> Lets say you have A->B(L).
>
> Process #2 locks B. The lock succeeds.
>
> Process #1 tries to lock A, and bloc
On 2006-02-09, Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote:
> i'm opposing the packaging of base, yet i'd like to see file=20
> registration (also for what somebody might call "package": sendmail,=20
> bind, whatever, basically what we have as WANT_* or NO_* already), so=20
> that stale fi
On 2006-02-07, Matthew Dillon <[EMAIL PROTECTED]> wrote:
>: - Unnecessary: shadow associatons can just be finely torn where they
>: were created: in the resolver routine. Propagating unresolution will
>: yield control back to the resolver routine, even if group topology is
>: left int
Hi,
Here is a revamp of the namecache coherency code (and nullfs).
I tried to follow the ideas we sort of agreed about in the thread "a take at
cache coherency", but real life wanted it differently sometimes...
- Diffstats:
kern/vfs_cache.c | 439 ++
On 2006-01-26, Justin C. Sherrill <[EMAIL PROTECTED]> wrote:
> Development has been somewhat slow, but I think that's in part because we
> went too long between releases, and some of the more interesting features
> are on hold until the subsystems are done. (Live CD with a desktop is
> dependent o
On 2006-01-24, Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote:
> actually I forgot about the need to have direct shadow associations and
> thought about a replacement. You are right, we can't do this.
Unless Matt tells us how to live without direct shadow associations...
> I'd still use a n
On 2006-01-24, Matthew Dillon <[EMAIL PROTECTED]> wrote:
> These are all very good ideas. I do have to agree with Simon re:
> the original patch. Its a bit too much of a hack. I still believe
> that nearly all the work should be in the cache_lock/unlock code
> and that most of t
On 2006-01-24, Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote:
> We need to linearize the cache entries anyways now, as we can't maintain
> a tree structure with doubly linked lists.
We don't need to linearize them. We can use the same tree layout as in
the fs hierarchy: pointers in one dire
On 2006-01-24, Csaba Henk <[EMAIL PROTECTED]> wrote:
> On 2006-01-23, Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote:
>> + renames on the lower layer don't trigger namecache
>> renames/invalidations on a higher layer.
[...]
> It's easy to
On 2006-01-23, Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote:
> + renames on the lower layer don't trigger namecache
> renames/invalidations on a higher layer. this is what the coherency
> should be about, i think.
OK, it took some time, but now I got your point. You are damn right.
While
On 2006-01-23, Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote:
> i'm sorry but i don't like the patch for those reasons. general vfs
> code gets cluttered with namecache interal going-ons (the shadow groups)
> and makes it super-easy to introduce a mistake.
Yeah, that's what's now. Though
Hi,
I sent a patch to submit@ implementing a kind of cache coherency:
http://leaf.dragonflybsd.org/mailarchive/submit/2006-01/msg00034.html
Pros:
Lightweight, in particular
- Unidirectonal synchronization. Only upper layers keep a reference to
lower ones, a lower ("shadowed") layer does
On 2006-01-21, Matthew Dillon <[EMAIL PROTECTED]> wrote:
> A devfs is not going to impact performance. That isn't the problem
> with it. There are three problems with it.
Maybe I missed something, but as I see this thread mentioned performance
only in connection with GEOM, not devfs.
>
On 2006-01-19, Erik V. Smith <[EMAIL PROTECTED]> wrote:
> If Matt, or anyone else very knowledgeable, would like to lead the way
> with designing a devd, I will implement it. If not, I'll do my best.
To start off, I'm not one of the very knowledgeable, yet I have an idea
of a "dynamic dev" soluti
On 2006-01-11, Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote:
> Matthew Dillon wrote:
>> cache_lock would create the namecache record in the lower layer
>> (recursively), and then operate in the same manner as if it exited in
>> the first place.
>
> The problem in this case is tha
On 2006-01-11, Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote:
> Csaba Henk wrote:
>>>I don't promise anything but try to stay tuned :)
>> Okay it seems Simon means getting this right so no need for me to play
>> the clever boy now.
>
> I
On 2006-01-10, Matthew Dillon <[EMAIL PROTECTED]> wrote:
> (2) Do not have a shadow callback. Instead have null_nresolve()
> call a new function, cache_shadow(), which creates the relationship
> between the upper and lower layer namecache records. Only
> null_nresolve() woul
On 2006-01-10, Csaba Henk <[EMAIL PROTECTED]> wrote:
> I don't promise anything but try to stay tuned :)
Okay it seems Simon means getting this right so no need for me to play
the clever boy now.
Csaba
On 2006-01-09, Simon 'corecode' Schubert <[EMAIL PROTECTED]> wrote:
> I know Matt wants a generic cache coherency layer, but until this is in
> place, I propose attached patch to fix this
> rename-race-and-file-vanishes bug in nullfs. Furthermore, you can't
> mount a nullfs from a nullfs as thi
On 2006-01-04, Emiel Kollof <[EMAIL PROTECTED]> wrote:
> On Monday 02 January 2006 22:12, Csaba Henk wrote:
>> Hm, I played a little bit with this. Here is a little test:
>
> [test snip]
>
>>
>> As of now, the effect not fatal... rather funny: after a while t
On 2006-01-02, Matthew Dillon <[EMAIL PROTECTED]> wrote:
> What a nice Christmas present! I was hoping someone would come along
> and rewrite nullfs!
It's good to hear that there is someone who thinks this day is still fine
as Christmas, as I have a nice pile of unanswered Xmas greetings
On 2006-01-02, Csaba Henk <[EMAIL PROTECTED]> wrote:
> I just posted two patches to submit@ which make nullfs work with the new
> namecache API (yes, it's without vnode overlaying).
Anchors for the future:
http://leaf.dragonflybsd.org/mailarchive/submit/2006-01/m
Hi!
I just posted two patches to submit@ which make nullfs work with the new
namecache API (yes, it's without vnode overlaying).
One is just the nullfs stuff, the other has a somewhat broader effect:
a rewrite of umount() which uses namecache rather than vnodes. It's
necessary for getting this st
33 matches
Mail list logo
