Nearer information is found here:
http://www.sun.com/2004-0914/feature/
http://en.wikipedia.org/wiki/ZFS
http://de.wikipedia.org/wiki/ZFS
ZFS would be an ideal file system for ReactOS and a hundred times better than the expired FAT. In addition, the ZFS source code is available. The "only" need is to port ZFS from OpenSolaris to ReactOS. Moreover, ZFS guarantees an absolute data security and shall be the fastest file system at all.
How about ZFS as ReactOS file system?
Moderator: Moderator Team
This Idea isn't even worth to be considered. ZFS can't be read or written by Windows, i don't even know if a linux driver exists. Also, since Windows uses NTFS, the ReactOS devs can't really avoid to implement it, and the ressources to develop zfs *and* ntfs drivers for ReactOS just aren't there. Ext2 is only being worked upon because good ext2 drivers for Windows exist, so it is the easiest way to get a proper file system (with permissions etc.) running on ReactOS until NTFS works. If you really want zfs support on ReactOS, write a windows driver and wait until ReactOS is able to load it. But don't expect anyone here to work on this, for there are things which are *much* more important.
No zfs driver for Linux as far as I know.
Lot of developers are talking about building it. Where else do you find a 128 bit file system.
Basicly we need the same translation to use zfs as what we need to use ext2.
Get Ext2 working then worry about zfs. Heck reactos is not 64 bit yet its going to have handling problems with the 128. Speed on 32 bit systems have been a question with zfs system.
Lot of developers are talking about building it. Where else do you find a 128 bit file system.
Basicly we need the same translation to use zfs as what we need to use ext2.
Get Ext2 working then worry about zfs. Heck reactos is not 64 bit yet its going to have handling problems with the 128. Speed on 32 bit systems have been a question with zfs system.
You just didn't understand what the 64 bit stuff is all about, so maybee you should consider not to talk about it.oiaohm wrote:No zfs driver for Linux as far as I know.
Lot of developers are talking about building it. Where else do you find a 128 bit file system.
Basicly we need the same translation to use zfs as what we need to use ext2.
Get Ext2 working then worry about zfs. Heck reactos is not 64 bit yet its going to have handling problems with the 128. Speed on 32 bit systems have been a question with zfs system.
A 64 bit CPU (SPARC, POWER, Itanium, AMD64/EM64T) means that the CPU's registers are 64 bits long, so an unsigned integer can be as big as 2^64-1. Also, with a 64 Bit memory bus you can handle up to 2^64 bytes of RAM. On a traditional 32-Bit-System, the maximum size of an unsigned integer would be 2^32-1, and you can only handle up to 2^32bytes=4GiB of RAM.Jaix wrote:Perhaps you could consider explaining the difference instead of flaming someone your post is totally usless to everyone except you.
A 128-Bit File system means that in the file system 128 bit pointers are used, so that you can handle up to 2^128 bytes. I don't really see the point since 64 Bit pointers are already big enough to manage up to 17179869184 Gigabytes.
These two things are completely independant though. As i said before, 32 Bits only allow you to manage up to 4 GiB of memory, so even today every file system able to handle more than 4 GiB must be using pointers longer than 32 bit.
All these things might not be precisely right, but you should have gotten the idea
Re: How about ZFS as ReactOS file system?
platon wrote:ZFS would be an ideal file system for ReactOS
S P R E A D T H E V O I C Eoiaohm wrote:zfs require the same translator.
ASK IT TO SUN !!!!
I think it would be realy interesting if some major will help (in any way) the ReactOS project.
»Forward Agency NPO
In progress we (always) trust.
In progress we (always) trust.
Re: How about ZFS as ReactOS file system?
i'm sure you were well-intentioned in posting this, but i wish people would learn the difference between true obsolescence, planned obsolescence, and Forced obsolescence-platon wrote:...and a hundred times better than the expired FAT.
FAT technology (at least where it includes FAT32 as a subset...) is an extremely desirable feature for ROS, for completely obvious reasons. that's got to be a large part of the reason why it already works, before they even bothered with ext2 support (which i also look forward to seeing in ros, but i don't mind the wait.)
if fat was truly yesterdays news, it wouldn't be in today's news, would it?
FOSS="MY Computer"
drm="NOT My Computer" http://eff.org
drm="NOT My Computer" http://eff.org
Heck post a short post and get Chewed.
Zfs is a unix based files system ie it needs a translator from unix permissions(Posix + ACL) to Windows permissions to work correctly in place of NTFS. This is what Ext 2 requires to be complete at ext2 level.
Reason for the 64 bit is handling if someone other than me had read the spec. Yes I did consider what I was talking about. There are a lot of 64 bit internal pointers.
How will a 32 bit OS handle this. Simplely split it into 2 32 bit pointers and take at least twice the time to processes normal average is about 2.5 the time out to a max of 3 times the time.
Zfs are self healing all the nice stuff. Base is really made for 64 bit operation. Its normal for the filesystem to be twice the size of the CPU in bits. Even the File Alocation Table operations are completely filled with unsigned 64 bit ints.
Its gets worse when you release that at times it even pushes a poor 64 bit processors. It has 256 bit check sums. SHA-256. Note these process alot faster on a 64 bit processor than a 32 bit one. Thinking that the check sum is required on write performing it needs to be fast.
2 to 64 — Number of zpools in a system
2 to 64 — Number of file systems in a zpool
Anyone looked Closely I guess not.
No one pulled me up for any chance of being wrong. Sun says its a 128 bit File system.
Its only 128 bit at a Single Zpool. Each file system is a 64 bit filesystem by 64 bit in a zpool equal 128 bit now 64 bit in zpools in a system equals a nasty 172 bit filesystem if you block it off into a single filesystem by its self. Sun is not planing to have to rewrite its filesystem any time soon for large systems.
Zfs is a unix based files system ie it needs a translator from unix permissions(Posix + ACL) to Windows permissions to work correctly in place of NTFS. This is what Ext 2 requires to be complete at ext2 level.
Reason for the 64 bit is handling if someone other than me had read the spec. Yes I did consider what I was talking about. There are a lot of 64 bit internal pointers.
How will a 32 bit OS handle this. Simplely split it into 2 32 bit pointers and take at least twice the time to processes normal average is about 2.5 the time out to a max of 3 times the time.
Zfs are self healing all the nice stuff. Base is really made for 64 bit operation. Its normal for the filesystem to be twice the size of the CPU in bits. Even the File Alocation Table operations are completely filled with unsigned 64 bit ints.
Its gets worse when you release that at times it even pushes a poor 64 bit processors. It has 256 bit check sums. SHA-256. Note these process alot faster on a 64 bit processor than a 32 bit one. Thinking that the check sum is required on write performing it needs to be fast.
2 to 64 — Number of zpools in a system
2 to 64 — Number of file systems in a zpool
Anyone looked Closely I guess not.
No one pulled me up for any chance of being wrong. Sun says its a 128 bit File system.
Its only 128 bit at a Single Zpool. Each file system is a 64 bit filesystem by 64 bit in a zpool equal 128 bit now 64 bit in zpools in a system equals a nasty 172 bit filesystem if you block it off into a single filesystem by its self. Sun is not planing to have to rewrite its filesystem any time soon for large systems.
-
Lucractius
- Posts: 47
- Joined: Fri Oct 21, 2005 4:27 am
I am looking forward.
Their are a lot of Posix filesystems. Zfs is the best of its type at this time.
If we can fill the Posix/Acl/ extend attributes translator to Windows Stuff. We will have all the Posix filesystems as options. Now is Zfs going to stay best of breed by the time Reactos get released. I don't know.
Will Posix filesystems with Acls and extend attributes be there. For sure. Will there be other developers in the Posix world who will see building a better filesystem than Zfs as a target For Sure someone will think they have a better methord and they just might.
Lets go after the small requirements that opens a lot of doors before going after the Big requirements that will take a lot of hours to complete.
Zfs will take a lot of hours. Ext2 fully operational is one step towards ZFS and may other filesystems more suited to the 32 bit world.
Their are a lot of Posix filesystems. Zfs is the best of its type at this time.
If we can fill the Posix/Acl/ extend attributes translator to Windows Stuff. We will have all the Posix filesystems as options. Now is Zfs going to stay best of breed by the time Reactos get released. I don't know.
Will Posix filesystems with Acls and extend attributes be there. For sure. Will there be other developers in the Posix world who will see building a better filesystem than Zfs as a target For Sure someone will think they have a better methord and they just might.
Lets go after the small requirements that opens a lot of doors before going after the Big requirements that will take a lot of hours to complete.
Zfs will take a lot of hours. Ext2 fully operational is one step towards ZFS and may other filesystems more suited to the 32 bit world.
Step by step
Hi,
I'm a mac guy who need some program only windows made. So for me, reactos should be a solution to use my win program beside osX in virtualisation mode (if the rumor of osX natively supporting win api should not materialize). Where looking foward to be 100% free of windows.
Development of opensource project need time. Yes zfs file system look good (rumors put it in the future osX filesystem). I'm looking foward to see it supported by reactos. Unfortunately it's better to spend time for now in the basic win compatibility than improving on windows. First fat32, in second ntfs at this point, hfs+ should bring many mac user who need to run win software but hate to have to format a win partition (my mac use hfs+, my externals drives fat and ntfs).
I know linux have a projet on hfs+ http://sourceforge.net/projects/linux-hfsplus (also http://www.ardistech.com/hfsplus/) if the description is right, windows is also supported so...
I'm a mac guy who need some program only windows made. So for me, reactos should be a solution to use my win program beside osX in virtualisation mode (if the rumor of osX natively supporting win api should not materialize). Where looking foward to be 100% free of windows.
Development of opensource project need time. Yes zfs file system look good (rumors put it in the future osX filesystem). I'm looking foward to see it supported by reactos. Unfortunately it's better to spend time for now in the basic win compatibility than improving on windows. First fat32, in second ntfs at this point, hfs+ should bring many mac user who need to run win software but hate to have to format a win partition (my mac use hfs+, my externals drives fat and ntfs).
I know linux have a projet on hfs+ http://sourceforge.net/projects/linux-hfsplus (also http://www.ardistech.com/hfsplus/) if the description is right, windows is also supported so...
Wine works on Mac OS X86. As long as your programs run in user mode (read: no drivers or the like), you should be able to run them with wine.
If you have a PowerPC based Mac, ReactOS won't run on your computer anyway. Even if ReactOS is ported to PowerPC, you won't be able to run regular windows programs with it, you'd have to compile them for PowerPC processors (unless the devs include a cpu emulator (for example Qemu), but then the programs will be too slow).
If you have a PowerPC based Mac, ReactOS won't run on your computer anyway. Even if ReactOS is ported to PowerPC, you won't be able to run regular windows programs with it, you'd have to compile them for PowerPC processors (unless the devs include a cpu emulator (for example Qemu), but then the programs will be too slow).
Who is online
Users browsing this forum: Google [Bot] and 34 guests