Date: Sun, 17 Mar 2002 08:49:34 -0500 From: Chris Mason <mason@suse.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Josh MacDonald <jmacd@CS.Berkeley.EDU>, Parity Error <bootup@mail.ru>, freebsd-fs@FreeBSD.ORG, reiserfs-dev@namesys.com Subject: Re: [reiserfs-dev] Re: metadata update durability ordering/soft updates Message-ID: <1870790000.1016372974@tiny> In-Reply-To: <3C93BBF1.7E8801DF@mindspring.com> References: <E16lReK-000C3T-00@f10.mail.ru> <3C910C57.71C2D823@mindspring.com> <20020315065651.02637@helen.CS.Berkeley.EDU> <3C923C91.454D7710@mindspring.com> <1562810000.1016224776@tiny> <3C928D21.404EA11D@mindspring.com> <1714680000.1016298986@tiny> <3C93BBF1.7E8801DF@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, March 16, 2002 01:41:05 PM -0800 Terry Lambert <tlambert2@mindspring.com> wrote: > Chris Mason wrote: >> Claim 44 is probably the most difficult, although I think this: >> >> "where said common writes and said function calls have common order >> dependencies CD1, CD2, . . . , CDcd that preserve the update order >> dependencies D1, D2, . . . , Dd between the operations in the requests, >> where cd is an integer, " >> >> Restricts it to systems that preserve the ordering of the requests >> inside the combined common write. In other words, if I batch >> mkdir foo ; mkdir foo2 into a common write, I think it says that >> mkdir foo will be done first. > > I can tell you from my experience with the source code that > this is not true, unless both updates occur in the same > directory entry block of the same directory. As long as any block ordering is still preserved, it isn't what reiserfs does. So, if in the common write, mkdir foo includes inter-ordering between foo's bitmap, directory, inode, etc, it excludes the write ahead logging we're using. Hans' bit about the reiserfs log not being new is entirely right. I was looking for simple, proven ideas when I started coding. But, I don't think DOW writes was one of them ;-) As for the rest, I'd rather not see a public discussin of the patent issues either. It just isn't interesting in the context of an operation system list, and I'm certainly not qualified from a patent law point of view anyway. Thanks to the pointers to sections of the patent doc. -chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1870790000.1016372974>