Some Questions & Suggestions

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Post Reply
Daniel Nikolic
Posts: 1
Joined: Wed Mar 28, 2007 10:54 am

Some Questions & Suggestions

Post by Daniel Nikolic »

I recenly found out about this website. I checked out the sources (great) and tried to run React OS under VMware player (not so great) and even tried some of my sw to run under it (disaster!).

I have a few questions:

1. I noted some inconsistencies in handling 8-bit/UTF-16 translation in ..A/..W calls between ...A functions in graphics (TextOut...) and synchronization (CreateSemaphore...). Graphics part always allocates memory (HeapAlloc) - a waste of time, IMHO.

2. I'm, not sure if is there a list of already checked/done, but not verified/not implemented API?

3. How could I help (I know some C)

Regards,

dn

hto
Developer
Posts: 2193
Joined: Sun Oct 01, 2006 3:43 pm

Post by hto »

You can talk about it with developers on #reactos IRC channel or via "Ros-Dev" mailing list.

Nande
Posts: 12
Joined: Sat Mar 31, 2007 9:00 am
Location: Argentina
Contact:

Post by Nande »

Hello, i hope noone would get angry because i reutilize this topic.
I just want to give a suggestion.
I would really like that reactos (in some future) makes fragmentation in the fs the less possible. and it'll b great that reatos couyld "defragment in the background". What i really mean is that it tries not to fragment while writing, not that it writes normally and then defrgaments.


I know that the devs are really busy with critical stuff, but i'd like just to suggest this for sometime when it can be affordable.

Regards.

oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm »

There is another solution to fragmentation. Just don't use fat32 and NTFS.

Problem window users are stuck with them. In time defrag in background might not be needed. As noted at top development to support other filesystem is under way.

Nande
Posts: 12
Joined: Sat Mar 31, 2007 9:00 am
Location: Argentina
Contact:

Post by Nande »

As reactos is aimed to be fully compatible, i just thought i'll be a nice add-on. Because i didn't thought they will drop Fat as a supported FS. but i guess most applications don't care what fs is installed.

Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Post by Z98 »

It's not that defragmentation isn't needed on other FS, it's more that some of them are really stupid on how they write out files. So files needed for a single app might be spread out across the harddrive, leading to longer read times to find them all. Now I'm not sure if the solution used in ext3 could work in NTFS to decrease single file fragmentation, but in general, ext3 does suffer from the way it writes files. Thus it's an annoyingly persistent myth that ext3 does not need defragmenting. And ultimately, there is no way to remove the need for defragmenting. You'll always have to deal with it sometime.

Some apps do care and want to be installed on NTFS, but they can be tricked. Whether you take a performance hit because of the translations is another matter entirely.

oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm »

True Ext3 will fragment under the right conditions. Its the deal with it sometime. Dealing with it once every 2 years is not a problem. NTFS is just fragmenting too fast yes might be fixable.

The difference is Linux Ext3 will self defrag too. Its not just writing. To cause ext3 to fragment need the drive filled to the last 10 percent and not fix this if the fragmented files are not written too.. So it runs out of room to move files around. As well adding and deleting ends up with segmented diskspace that can cause fragmenation. Yes Ext filesystems are not perfect. If Ext system is writing to a file that is fragmented and it gets processor time it will move and defrag the file.

MS NTFS driver has close to anti-fragmentation as ext3 on creating new files. MS NTFS driver does not handle appending to files to prevent fragmentation. Ie MS NTFS is not prepared to bite the bullet and move a file to keep it non fragmented if there is the space.

So its not exactly running a defrag in background. Lots of filesystems have more advanced fragmentation resistance than NTFS. Fat has no fragmentation resistance at all so it fragments like lighting.

The resistance need to increased. The advantage of the Ext3 operations is there is not constant load caused by it.

Note Linux's user space defrag does not use any other operations than read and write to defrag the fileystem. This will work with NTFS as well very messy but will work but complete fails with fat. I have use the same method on NTFS partitions that will not defrag any more with Microsoft Defrag. So they did code in some fragmentation resistance that works but just not enough to keep it down to a reasonable time between defrags.

Nande
Posts: 12
Joined: Sat Mar 31, 2007 9:00 am
Location: Argentina
Contact:

Post by Nande »

Thanks a lot, that's what i was talking about.
I don't really know so much about the MS and ExtX FS. but i knew they had a built in feature to avoid fragment files so fast.

i think i'll be a nice feature _in the future_ to suport something like this, even in Fat32

oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm »

High level fragmentation resistance to do effectively requires data in the file system to make it quick to know if something is fragmented or not. And quick to find what free none fragmented storage blocks. I don't know if its fast to find out in NTFS if a file is fragmented it might be the reason why its behind Ext3.

The required features don't exist in Fat32 to create any fragmentation resistance. The way fat32 works its slow to find unfragmented blocks. Sorry to say stuck with running a defrag program on it. Only long term option is somehow fat32 has to go into history for good.

Even the latest ext4 and zfs has added a new features for resistance to fragmentation.

I know most people hate hearing this. That what can be done to stop fragmentation at runtime depends heavily on the file system.

Nande
Posts: 12
Joined: Sat Mar 31, 2007 9:00 am
Location: Argentina
Contact:

Post by Nande »

if i could choose, i'd like that the official FS would b ext3/4 or another with good performance and features, and besides, try to avoid microsoft owned things, (cuz, a) i don't like them. and b) legal purpouses)
I mean, if it doesn't low the compatibility.

but i'm not the one to choose, are the devs aware of this? what do they think?

Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Post by Z98 »

Reason A the devs are going to ignore. They simply don't care if people dislike MS and will do whatever they wish. As far as legal issues go, that may or may not matter. If MS attacked ReactOS for using NTFS, they'd by extension be attacking all the other NTFS projects out there, for we'd be using their resources as a reference at the very least. Whether MS wants to draw the wrath of all the Linux users that depend upon those projects, it's up to them. But they're not suicidal.

Whether NTFS is absolutely needed for compatibility is somewhat a question mark. It would be far easier and better performance wise to be using NTFS instead of translating calls programs make to NTFS so they will work on ext3/4 or any other FS. Some programs take advantage of the security features MS put into NTFS and that's something that must be dealt with. Writing the driver itself will be fairly difficult, but then again, doing the translations will be as well. And finally, a lot of us have drives formatted as NTFS to begin with, and I have no intention of starting from scratch. I want to keep using them without having to worry about things.

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot] and 19 guests