For the last couple of weeks we've been making some important format changes for OCFS2. We're not done yet, but much of it is in a state where we feel it can be merged back into trunk and played with. There are bugs, and there will be more disk format changes, but at least now others can pitch in. You will absolutely have to reformat your filesystems after picking up this revision (946). The userspace tools aren't as ready for ocfs-tools trunk yet though, so you'll need to pick up the new-dir-format branch of ocfs-tools and use that to create ocfs2 file systems. $ svn co http://oss.oracle.com/projects/ocfs-tools/src/branches/new-dir-format/ ocfs-tools Those of you who have read the ext3 code might find some of this new stuff familiar. This is because we've finally done away with our dirnode structures and gone to something a little less... broken :) --Mark -- Mark Fasheh Software Developer, Oracle Corp mark.fasheh@oracle.com
Is there any simple description about the changes of the format?=20 Are there still 8 system files. Is the file entry still store in DirNode?>-----Original Message----- >From: ocfs2-devel-bounces@oss.oracle.com=20 >[mailto:ocfs2-devel-bounces@oss.oracle.com] On Behalf Of Mark Fasheh >Sent: 2004=C4=EA5=D4=C227=C8=D5 9:16 >To: ocfs2-devel@oss.oracle.com=20 >Subject: [Ocfs2-devel] [IMPORTANT] OCFS2 revision 946 > >For the last couple of weeks we've been making some important=20 >format changes >for OCFS2. We're not done yet, but much of it is in a state=20 >where we feel it >can be merged back into trunk and played with. There are bugs,=20 >and there >will be more disk format changes, but at least now others can pitch in. > >You will absolutely have to reformat your filesystems after=20 >picking up this >revision (946). The userspace tools aren't as ready for=20 >ocfs-tools trunk yet >though, so you'll need to pick up the new-dir-format branch of=20 >ocfs-tools >and use that to create ocfs2 file systems. > >$ svn co=20 >http://oss.oracle.com/projects/ocfs-tools/src/branches/new-dir- >format/ ocfs-tools > >Those of you who have read the ext3 code might find some of=20 >this new stuff >familiar. This is because we've finally done away with our dirnode >structures and gone to something a little less... broken :) > --Mark > >-- >Mark Fasheh >Software Developer, Oracle Corp >mark.fasheh@oracle.com >_______________________________________________ >Ocfs2-devel mailing list >Ocfs2-devel@oss.oracle.com >http://oss.oracle.com/mailman/listinfo/ocfs2-devel >
So seems the file_entry struct is much like the ext2_inode struct in ext2/3 file system now. Another effect is we lose a simple way to list the all files without going to each directory recursively.:) How about the root, is there a file_entry for root directory and as the first one in "inode alloc" file?>-----Original Message----- >From: Mark Fasheh [mailto:mark.fasheh@oracle.com]=20 >Sent: 2004=C4=EA5=D4=C227=C8=D5 13:50 >To: Ling, Xiaofeng >Cc: ocfs2-devel@oss.oracle.com >Subject: Re: [Ocfs2-devel] [IMPORTANT] OCFS2 revision 946 > >Sure. The other OCFS2 hackers can correct any details I get wrong: >File entries, for now, are largely unchanged. the filename and=20 >filename_len >fields are gone however as they're stored in directories now. > >Directories store filename and offset information in their=20 >data blocks now. >This has the big advantage of reducing the overhead of things like >readdir(), and seperates the namespace data from the inode=20 >data so that you >can do things like renames and link and whatnot without coping=20 >file entries >around. A file entry now will *never* change offset. Making=20 >links to file >entries is as easy as incrementing link count and storing=20 >another name / >offset (remember offset will be the same though) pair in the=20 >directory data. > >renaming a file doesn't even require locking the file entry. We simply >change the name data in the directory (or directories if we're=20 >renaming to a >new one). Similarly, unlinking only requires we remove the=20 >name / offset >pair from the directory. > >Since there's no more dir nodes, there's no dir alloc file / dir alloc >bitmap file. file entries are now allocated out of a new=20 >"inode alloc" file >using an inode alloc bitmap. These function just like the=20 >other metadata >allocator file(s) did before. The other system files are unchanged. > >Hopefully I've managed to clear things up a bit... > --Mark > >On Thu, May 27, 2004 at 11:26:49AM +0800, Ling, Xiaofeng wrote: >> Is there any simple description about the changes of the format?=20 >> Are there still 8 system files. Is the file entry still=20 >store in DirNode? > >-- >Mark Fasheh >Software Developer, Oracle Corp >mark.fasheh@oracle.com >
Hi Mark, Do you plan to add more format changes to the OCFS2 recently?=20 We are now working on stabilize the OCFS2 on top of IPF and kernel 2.6. We hope we can get a stable release for kernel 2.4 and IA32. What's your plan? Thanks. ********************************************* Sonic Zhang Software Engineer Intel China Software Lab Tel: (086)021-52574545-1667 iNet: 752-1667 *********************************************=20 -----Original Message----- From: ocfs2-devel-bounces@oss.oracle.com [mailto:ocfs2-devel-bounces@oss.oracle.com] On Behalf Of Mark Fasheh Sent: 2004=C4=EA5=D4=C226=C8=D5 18:16 To: ocfs2-devel@oss.oracle.com Subject: [Ocfs2-devel] [IMPORTANT] OCFS2 revision 946 For the last couple of weeks we've been making some important format changes for OCFS2. We're not done yet, but much of it is in a state where we feel it can be merged back into trunk and played with. There are bugs, and there will be more disk format changes, but at least now others can pitch in. You will absolutely have to reformat your filesystems after picking up this revision (946). The userspace tools aren't as ready for ocfs-tools trunk yet though, so you'll need to pick up the new-dir-format branch of ocfs-tools and use that to create ocfs2 file systems. $ svn co http://oss.oracle.com/projects/ocfs-tools/src/branches/new-dir-format/ ocfs-tools Those of you who have read the ext3 code might find some of this new stuff familiar. This is because we've finally done away with our dirnode structures and gone to something a little less... broken :) --Mark -- Mark Fasheh Software Developer, Oracle Corp mark.fasheh@oracle.com _______________________________________________ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com http://oss.oracle.com/mailman/listinfo/ocfs2-devel