I see that some of the newer e2fsprogs have support to set the stride/stripe parameters for a filesystem. Do these options require any kernel-level support to work? It would seem that new functionality would require updates to the ext3 code in the kernel, but I didn't see any mention of that. Maybe these parameters get implemented through some existing functionality?
Thanks,
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the reading material, I will start checking those out. I noticed that you only mentioned EXT4 - does that mean that EXT3 does not support these features?
My storage system consists of hundreds of servers each with multiple TBs of storage all on EXT3. The data is very important. Do you feel that EXT4 is at least 98% as stable as EXT3?
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I'm using ext4 on my laptop, and I haven't lost any data yet.
That being said, we are still getting bug reports from end users which we are fixing. I can't honestly recommend it for you to use on really critical production servers just yet. On the other hand, this would be a great time for you to experiment with ext4 to see how it works for you, and so if there are any problems in the ext4 code that would be exposed by your particular workload and how you use the filesystem, we can find out and fix it.
In answer to your question, yes, ext3 won't know how to deal with the RAID settings. The development strategy that we've followed has been to add new features to ext4 in order to make sure that there's no possibility that we could potentially add bugs to ext3 --- ext3 is such a popularly used filesystem that we have to be very careful before we make changes, and there were many advanced features that have been added to ext4. The last thing we want to do is accidentally cause data loss for ext3 users. So even though we do a lot of testing, the best way to make sure ext3 doesn't get any new bugs is to not add any new features to it. :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see that some of the newer e2fsprogs have support to set the stride/stripe parameters for a filesystem. Do these options require any kernel-level support to work? It would seem that new functionality would require updates to the ext3 code in the kernel, but I didn't see any mention of that. Maybe these parameters get implemented through some existing functionality?
Thanks,
Mike
The multiblock allocator in ext4 will take advantage of these settings.
Ext4 is quite stable at this point, and its performance is far superior to ext3. Please see:
http://thunk.org/tytso/blog/2008/08/08/fast-ext4-fsck-times/
http://thunk.org/tytso/blog/2008/06/30/ext4-is-now-the-primary-filesystem-on-my-laptop/
and if you want to use ext4, please see:
http://ext4.wiki.kernel.org/index.php/Ext4_Howto
Thanks for the reading material, I will start checking those out. I noticed that you only mentioned EXT4 - does that mean that EXT3 does not support these features?
My storage system consists of hundreds of servers each with multiple TBs of storage all on EXT3. The data is very important. Do you feel that EXT4 is at least 98% as stable as EXT3?
Mike
Well, I'm using ext4 on my laptop, and I haven't lost any data yet.
That being said, we are still getting bug reports from end users which we are fixing. I can't honestly recommend it for you to use on really critical production servers just yet. On the other hand, this would be a great time for you to experiment with ext4 to see how it works for you, and so if there are any problems in the ext4 code that would be exposed by your particular workload and how you use the filesystem, we can find out and fix it.
In answer to your question, yes, ext3 won't know how to deal with the RAID settings. The development strategy that we've followed has been to add new features to ext4 in order to make sure that there's no possibility that we could potentially add bugs to ext3 --- ext3 is such a popularly used filesystem that we have to be very careful before we make changes, and there were many advanced features that have been added to ext4. The last thing we want to do is accidentally cause data loss for ext3 users. So even though we do a lot of testing, the best way to make sure ext3 doesn't get any new bugs is to not add any new features to it. :-)