Who says it will only be included for compatibility?
I don’t see an open source NTFS being developed any time
soon, if at all, and I’m not overly keen on all these unix file systems.
For the foreseeable future FAT is by far the best option for us.
If we can add journaling then all the better.
If we could also add optional ACL support without breaking compatibility
when we’d have a pretty good file system to move forward with.
Ged.
From: ShadowFlare [mailto:blakflare@gmail.com]
Sent: 30 July 2009 11:06
To: ReactOS Development List
Subject: Re: [ros-dev] FullFAT replacement for Fastfat.sys
What happens if another OS makes changes, not knowing about
the journal? Does the journal need to be rebuilt (either partially or
fully)? FAT support would mainly be for compatibility with another OS, so
it is pretty much certain that another OS would be writing files onto the file
system.
Also, are there really any compelling reasons to add a
ReactOS-only feature to a file system that later will be supported mainly only
for compatibility?
-ShadowFlare
On Thu, Jul 30, 2009 at 2:36 AM, Aleksey Bragin <aleksey@reactos.org> wrote:
I'll explain the FAT journalling part, it's the idea I had
for quite a while, and mainly it's just an experimental, fun idea.
So far FAT provides no consistency of neither metadata nor
actual data. In order to maintain consistency, the filesystem's integrity has
to be verified and fixed at every boot if not clean shutdown is detected.
Now, if we add a special file, let's say our driver knows
its placement for sure, and that file doesn't change size and is not movable,
we can implement transactional writing of metadata to the FAT directory entries
using this file as a journal.
Advantages:
- Compatibility with original FAT drivers (without
journalling of course)
- Metadata is always consistent (no need for a checkdisk).
Disadvantages:
- Please name them.
I suppose that's how ext3 was done from ext2. Why making the
same from FAT would be a bad idea?
WBR,
Aleksey Bragin.
On Jul 30, 2009, at 1:52 AM, Pierre SCHWEITZER wrote:
Hi,
"I'm still at a loss as to why you are all ignoring the free, open source,
FastFAT driver in the Microsoft WDK.". Wasn't it some kind a license
problem? EULA, or something like that? The question rose when ARM ninjas
imported CDFS driver from the Microsoft WDK. They finally had to remove it.
Anyway, that's not exactly the point.
Regarding your initial question, for FSD an important part is missing in
ReactOS: FsRTL package. Moreover, you may (or, you will?) have problems using
CC package. But, that's a good point in fact. That way, we'll be able to
implement/debug the needed functions, with test case.
Finally, I'd like to come back on that idea: "During the conversation we
also discussed implementing a special journaling extension to FullFAT via the
windows driver.". I've to admit I don't see how it can be a good idea. IF
everything goes well, ReactOS will be able to handle two journalised FS: NTFS
and ext3. Those are known, and used FS. Why should we create a
"super" FAT instead of using those FS? What about compatibilty?
A better idea would to handle exFAT...
Best regards,
P. Schweitzer
From: ionucu@videotron.ca
To: ros-dev@reactos.org
Date: Wed, 29 Jul 2009 14:00:08 -0700
Subject: Re: [ros-dev] FullFAT replacement for Fastfat.sys
I'm still at a loss as to why you are all ignoring the free, open source,
FastFAT driver in the Microsoft WDK.
On 29-Jul-09, at 10:56 AM, Gabriel ilardi wrote: