You sure it was ported AIX -> OS/2, and not the other way around? WBR // Love
On Tue, Apr 5, 2011 at 5:57 PM, Adam <[email protected]> wrote: > AFAIK only NTFS has this root; JFS has been around for a while in the AIX > systems. It was ported to OS/2 Warp 4.5 later on. > > Well at least they're both better than all that > ext1/ext2/ext3/ext4/extπ/whatever gibberish. The biggest problem is (and it > has actually happened to me before) these guys can run out of "inodes" and > what not. > > > On Tue, 05 Apr 2011 19:40:09 +1000, Love Nystrom <[email protected]> > wrote: > > Hi Adam, >> >> Thanks for the pointer. >> JFS may be a viable alternative to NTFS indeed, they probably have the >> same >> root (HPFS)? >> >> The bulk of porting it to ReactOS will probably be "un-porting" it's Linux >> kernel dependency patches. >> I'm fetching the whole CVS repository from SourceForge right now, but I'm >> not sure when >> I will get the time to start eyeballing it .. I should be doing RL stuff >> today but find my butt >> glued to the chair again >> (Water_stoppage==Shower_impossible==I_refuse_to_go_public)! >> >> Peace >> // Love >> >> On Tue, Apr 5, 2011 at 3:02 PM, Adam <[email protected]> wrote: >> >> I would also recommend looking at porting JFS - the sources are >>> available. >>> This is the file system that IBM originally used in OS/2 Warp 4.5X (and >>> also >>> AIX if I am not mistaken) and is a very solid file system. Something IBM >>> seemed to be doing right. >>> >>> I am not sure about all the details of it, but AFAIK it also supports >>> things like ACLs too. >>> >>> >>> On Tue, 05 Apr 2011 17:56:40 +1000, Love Nystrom <[email protected] >>> > >>> wrote: >>> >>> Hi Bryan, >>> >>>> >>>> Just like Aleksey, I would welcome an effort to simplify IFS >>>> implementation. >>>> >>>> Seen as NTFS is (and always will be?) not well documented, I've been >>>> thinking about >>>> supporting some alternative, OSS, journaling file system in ReactOS, >>>> e.g. >>>> ReiserFS, >>>> to allow us to provide the (relative) fail-safety of file transaction >>>> journaling that NTFS has. >>>> Also, hopefully, to enable us to implement NT's access privilege >>>> system (Security) on files. >>>> >>>> So far, it remains just a thought, since I can't allocate the time to >>>> adapt >>>> e.g ReiserFS to >>>> an NT IFS, and if I'm not mistaken, our IFS implementation has >>>> shortcomings >>>> of it's own >>>> which You may need to address as well in implementing Your proposal. >>>> >>>> In addition to "Windows NT File System Internals" I would also recommend >>>> "Windows Internals, 4th Edition" for additional/complementary insight. >>>> Especially Ch.12 "File Systems", but Ch.8-12 are all relevant, and the >>>> whole >>>> book is strongly recommended (by everyone, I think). >>>> >>>> It will be a BIG job I think (thesis big), and I hope You have the >>>> structural >>>> "common sense" to make it a success, and not a mess ;). >>>> It would be most welcome ! >>>> >>>> Comment Your code scrupulously :) >>>> >>>> Best Regards >>>> // Love >>>> >>>> On Sun, Apr 3, 2011 at 1:55 PM, <[email protected]> wrote: >>>> >>>> ---------- Forwarded message ---------- >>>> >>>>> From: Bryan Donlan <[email protected]> >>>>> To: ReactOS Development List <[email protected]> >>>>> Date: Sat, 2 Apr 2011 18:26:23 -0400 >>>>> Subject: [ros-dev] [GSoC] IFS wrapper project proposal draft >>>>> Hello, >>>>> >>>>> After reading the ReactOS GSoC ideas page, I became interested in the >>>>> IFS wrapper driver project idea[1], and would appreciate any comments >>>>> on my project proposal before I formally submit it. >>>>> >>>>> First, a bit about me. I am a student in a dual-major program, >>>>> studying Computer Science and Japanese at the University of >>>>> Massachusetts at Amherst. I have had some experience in kernel >>>>> development previously; as part of an internship at a research project >>>>> at my University, I wrote some network flow analysis code running in >>>>> the Linux kernel. While filesystem work will be a first for me, I >>>>> think it will be an interesting leaning experience. I am fluent in >>>>> English and Japanese, and am in the UTC-0400 timezone (TZ=US/Eastern). >>>>> My freenode username is bd_, and my myReactOS username is bdonlan. >>>>> >>>>> In preparation for writing this proposal, I obtained a copy of the >>>>> "Windows NT File System Internals: A Developer's Guide" book from >>>>> O'Reilly. Although a bit dated, it has been enourmously helpful in >>>>> helping me get an idea of what I'm getting into. >>>>> >>>>> My goal in this project will be to write a library to significantly >>>>> simplify writing a NT File System Driver. Although writing a >>>>> kernel-mode filesystem will never be as easy as with, eg, FUSE, it >>>>> should be possible to abstract away many of the idiosyncracies of the >>>>> NT filesystem API, at least. For example, the wrapper library may >>>>> handle: >>>>> * Automatically queueing asynchronous filesystem operations on a worker >>>>> thread >>>>> * Parsing paths and invoking a FS-supplied traversal function for each >>>>> directory element >>>>> * Interfacing with the NT cache manager, including flushing data from >>>>> the cache when a non-cached operation is performed on a cached file, >>>>> and establishing cache maps for the underlying device for a disk-based >>>>> file system >>>>> * Providing a common implementation of byte range locks and oplocks, >>>>> and disabling fast I/O when they are in use >>>>> * Caching directory entry lookups >>>>> * Performing typical input validation/security checks needed by all NT >>>>> filesystems >>>>> * Helper tools may also be provided to load pseudo-filesystems >>>>> (filesystems with neither network nor disk backing) on an ad-hoc basis >>>>> >>>>> Essentially, the library should make it easy for the filesystem >>>>> designer to focus on the actual filesystem, rather than the NT IFS >>>>> interfaces - a read call would be able to skip all the preparation and >>>>> checks, and directly go to perform the actual I/O. >>>>> >>>>> Major milestones for the project may include: >>>>> - Prepare a sketch of the API and callbacks for the IFS helper library >>>>> (subject to change if necessary) >>>>> - Implement enough of the wrapper library to implement a simple >>>>> pseudo-filesystem demonstrating non-cached reads and writes >>>>> - Add support for cached reads/writes (interaction with the cache >>>>> manager, caching for on-disk metadata) >>>>> - Demonstrate a disk-based filesystem without metadata update support >>>>> (MINIX FS or FAT?) >>>>> - Demonstrate a disk-based filesystem with full read-write support >>>>> - If time allows, add support for ancillary features, such as byte >>>>> locks, oplocks, and notify watchers. >>>>> >>>>> The interfaces exposed by the filesystem library will of course be >>>>> clearly documented. Filesystems needing more advanced support will >>>>> also be able to override any IFS callbacks they choose. >>>>> >>>>> I have an existing consulting commitment that will take some of my >>>>> time, but I expect to be able to put in 20-30 hours of work per week >>>>> into this project. Further, I hereby swear that I have not used nor >>>>> seen the source code to any version of the Windows operating system >>>>> nor any Microsoft product that may be related to the proposed project >>>>> that is under a license incompatible with contribution to ReactOS, >>>>> including but not limited to the leaked Windows 2000 source code and >>>>> the Windows Research Kernel. >>>>> >>>>> I would appreciate any comments on my proposal before formally >>>>> submitting it to the GSoC site. >>>>> >>>>> Thanks, >>>>> >>>>> Bryan Donlan >>>>> >>>>> >>>>> >>>>> >>> -- >>> Using Opera's revolutionary email client: http://www.opera.com/mail/ >>> >>> > > -- > Using Opera's revolutionary email client: http://www.opera.com/mail/ >
_______________________________________________ Ros-dev mailing list [email protected] http://www.reactos.org/mailman/listinfo/ros-dev
