Date: Sat, 16 Mar 2002 12:16:26 -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: <1714680000.1016298986@tiny> In-Reply-To: <3C928D21.404EA11D@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, March 15, 2002 04:09:05 PM -0800 Terry Lambert <tlambert2@mindspring.com> wrote: > Chris Mason wrote: >> I haven't read the entire patent, but maybe you can point me to the >> paragraphs where it covers write-ahead logging in the description. > > A subset of writes to secondary storage are performed > using a Delayed Ordered Write (DOW) subsystem, which > makes it possible for any file system to control the > order in which modifications are propagated to disk. > The DOW subsystem consists of two parts. The first > part is a specification interface, which a file system > implementation or any other kernel subsystem can use > to indicate sequential ordering between a modification > and some other modification of file system structural > data. > > This is the write-ahead log. The only difference is where it's > stored: in memory or on disk. Well, I'm certainly not a patent lawyer, but the way they define this interface seems very different from the way reiserfs works. The interface a) is not available to the kernel or any other subsystem and b) does not define ordering. It defines atomic units consisting of multiple operations. > The second part of DOW subsystem is a mechanism that > ensures that the disk write operations are indeed > performed in accordance with the order store. DOW > improves computer system performance by reducing disk > traffic as well as the number of context switches > that would be generated if synchronous writes were > used for ordering. > > See also claims 1, 6, 23, and 44. 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. > > >> Durning any operation, no attempt at all is made to order the writing >> of the bitmap, the inode, the directory entries, or any other part of >> the metadata. It simply makes sure that after a crash the operations >> are either completed or not. If you mkdir foo and then mkdir foo2, >> it is entirely possible the blocks for foo2 go to disk first. > > I didn't say it infringed Soft Updates (which does this), I > said it infringed DOW (which doesn't). I got that idea from this paragraph: "DOW includes two parts. The first part is an interface by which file system implementations, or any kernel subsystem, specify the sequences in which modifications of file system data blocks can be recorded on disks. These sequences translate into ordering dependencies among disk blocks themselves, which are collectively represented by an ordering graph (entries in an ordering store), prepared by DOW in response to the specification." If this has been discussed in detail already, please drop me a link to the mailing list archive. -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?1714680000.1016298986>