Anyone tracking svn for the last week or so has probably noticed the large number of changes happening to the code base. We're making some disk format changes, so people tracking ocfs2 will also have to closely track ocfs-tools trunk. Also, be prepared to have to reformat your file systems :) As far as what we're actually doing -- we're (finally!) fixing the directory layout issues we've been living with for a while. Directories are going to be alot closer to an ext2/3 style layout where names and offsets will be allocated in the directory extent pointers much like regular file data. This allows us to make namespace changes (mknod, delete, rename) in the directory metadata without having to read the actual file entries off disk. Further, it should greatly reduce the amount of I/O required to do a simple readdir style operation. Most importantly, we won't have to lock out inode blocks for namespace operations any more, and this will open the door towards dumping the bh hash and using more traditional methods of locking blocks under change. --Mark -- Mark Fasheh Software Developer, Oracle Corp mark.fasheh@oracle.com
Always wondered why the directory structures on disk were so funky. Very cool... looking forward to seeing the improvements and trying it out on a test cluster... :) Jeremy Jeremy Schneider Database/Systems Administrator The ASU Group - IS Dept email: jer1887@asugroup.com>>> Mark Fasheh <mark.fasheh@oracle.com> 05/06/2004 4:20:47 PM >>>Anyone tracking svn for the last week or so has probably noticed the large number of changes happening to the code base. We're making some disk format changes, so people tracking ocfs2 will also have to closely track ocfs-tools trunk. Also, be prepared to have to reformat your file systems :) As far as what we're actually doing -- we're (finally!) fixing the directory layout issues we've been living with for a while. Directories are going to be alot closer to an ext2/3 style layout where names and offsets will be allocated in the directory extent pointers much like regular file data. This allows us to make namespace changes (mknod, delete, rename) in the directory metadata without having to read the actual file entries off disk. Further, it should greatly reduce the amount of I/O required to do a simple readdir style operation. Most importantly, we won't have to lock out inode blocks for namespace operations any more, and this will open the door towards dumping the bh hash and using more traditional methods of locking blocks under change. --Mark -- Mark Fasheh Software Developer, Oracle Corp mark.fasheh@oracle.com This message (including any attachments) contains confidential information intended for a specific individual(s) and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, by anyone other than the intended recipient(s), is strictly prohibited. <<<<...>>>>
Ok, ignore this e-mail for ocfs v1. I sent it to ocfs-devel instead of ocfs2-devel! Sorry 'bout that. So just to recap, those changes *are* happening, but NOT to ocfs version 1, which should not have any on disk changes for the rest of it's lifetime. Again, apologies for any confusion this may have caused! --Mark On Thu, May 06, 2004 at 01:20:47PM -0700, Mark Fasheh wrote:> Anyone tracking svn for the last week or so has probably noticed the large > number of changes happening to the code base. > > We're making some disk format changes, so people tracking ocfs2 will also > have to closely track ocfs-tools trunk. Also, be prepared to have to > reformat your file systems :) > > As far as what we're actually doing -- we're (finally!) fixing the > directory layout issues we've been living with for a while. Directories are > going to be alot closer to an ext2/3 style layout where names and offsets > will be allocated in the directory extent pointers much like regular file > data. This allows us to make namespace changes (mknod, delete, rename) in > the directory metadata without having to read the actual file entries off > disk. Further, it should greatly reduce the amount of I/O required to do a > simple readdir style operation. Most importantly, we won't have to lock out > inode blocks for namespace operations any more, and this will open the door > towards dumping the bh hash and using more traditional methods of locking > blocks under change. > --Mark > > -- > Mark Fasheh > Software Developer, Oracle Corp > mark.fasheh@oracle.com-- Mark Fasheh Software Developer, Oracle Corp mark.fasheh@oracle.com