Blog Entry

mge1512's picture
blog
Reads:

3200

Score:
2.75
2.8
4
 
Comments:

3

Data is Customers' Gold!

(View Disclaimer)

Data is Customers' Gold,
the Operating System the Bank,
the Filesystem the Vault.

Discussing "Choice" last year, I already mentioned that we are proud to have certified all primary local filesystems in SUSE Linux Enterprise 11 (ext3, xfs, reiserfs) with major storage systems, and provide the best scaling choice for storage from desktop to datacenter (SUSE Linux Enterprise 11 Service Pack 1 Specifications).

When we introduced reiserfs into SUSE Linux Enterprise Server 7 in 2000, there was no choice: no other journaling filesystem had been ready, and we were the first to support a journaling filesystem in an Enterprise Linux at all.

With SUSE Linux Enterprise Server 8 reiserfs became the default filesystem. In 2002 we also started to support xfs, at that time the only Linux filesystem to support POSIX ACLs and extended attributes.

With filesystem deployments beyond 64 TiB, xfs is still the leading local Linux filesystem with respect to scalability.

At the time reiserfs was the only choice, but it is not first choice anymore; there are other options, and as product manager you have to decide how to develop and where to go -- based on market research, customer feedback and technical advice by the engineering team.

The most important argument when discussing filesystems and their support is the question of customer data, existing and future deployments:

You don't want to leave customers in a situation where they cannot access their data anymore. That's why SUSE Linux Enterprise Server 11 Service Pack 1 still comes with a jfs module, even though we started deprecating this filesystem with SUSE Linux Enterprise Server 10 three years ago.

The second most important question is where you want to invest, where you want to put your resources -- which horse you want to bet on.

The Enterprise Linux area is special, as you are on the one hand competing with proprietary operating systems. On the other hand you are part of a community ecosystem, which you are eating from, and which you are feeding. This community does not always speak with one voice.

Back in the filesystem area now, there is an emerging trend to agree on btrfs as the local filesystem for Linux, and some non-Enterprise Linux distributions already have chosen it as their default.

When planning SUSE Linux Enterprise Server 11 two years ago, we discussed btrfs and its capabilities as part of our strategy, but btrfs is not yet stable enough to protect our customer's gold, thus provided as a Technology Preview in SUSE Linux Enterprise Server 11 Service Pack 1; we expect btrfs to be in an enterprise-ready status end of 2011.

That said, btrfs is the direction to go. Btrfs is the horse we are investing in for the future.

On the flip side, this means that there are horses we do not bet on -- and those we are not even willing to feed. Ext4 is one of those.

The table below may give you an idea why this decision is also backed by a number of technical arguments.

Feel free to comment!

 

Comparison ext4 vs. btrfs

feature ext4 btrfs
block allocation extents extents
metadata format classic unix-inode btree items
metadata replication yes, with raid yes, native
metadata integrity no yes
data replication yes, with raid yes, native or with RAID
data integrity no yes
replication policy no yes
prioritized storage pools no yes
fs-global snapshot yes, with lvm yes, native
directory snapshot no yes
copy-on-write no yes
extended attributes yes yes
POSIX ACLs yes yes
online ext3 conversion yes no
offline ext3 conversion yes yes
reversible ext3 conversion no yes
delayed allocation yes yes
user/group quotas yes subvolumes
subvolume quotas n/a yes
ssd-optimized mode no yes
online fsck no yes
online defrag no yes
extensible metadata format yes yes
inode attributes yes yes
indexed directories yes yes
efficient small file storage yes yes
clusterable no no
distributed no no
active community yes yes, strong

 

Frequently asked questions

Q 1. Which filesystem should I choose for a new deployment?
For a discussion about different filesystems and their optimal use case, compare the recent article in Novell's Connection Magazine "Two Paths to Server Performance -- I/O scheduler and file system selection can boost SUSE Linux Enterprise server performance"
.
Q 2. SUSE Linux Enterprise Server 12 will be released about 3-4 years after SUSE Linux Enterprise Server 11, and you say that you are considering to not support creation of new reiserfs filesystems by then. Should I deploy new data on reiserfs today? Can I keep existing reiserfs filesystem?
Yes and Yes. reiserfs for existing deployments is expected to be fully supported by SUSE Linux Enterprise Server 12, i.e. for at least 10 years from now.
Q 3. But isn't ext4 just "the better ext3" as ext3 was ext2 plus journaling support?
Yes and no. There are some features in ext4 that can be used without breaking compatibility with the ext3 disk format but most useful ones require altering the file system in an incompatible manner. Since we have been offering these features using different file systems for years, we chose not to introduce potential instability with little improvement in functionality.

Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).

It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.




User Comments

FlyingGuy's picture

NSS is still better

Submitted by FlyingGuy on 9 August 2010 - 3:56pm.

Novell Storage Services is by far still the most robust and complete file system available.

Novell is throwing out the baby with the bathwater. NSS could be ported to *nix and extended far beyond bfrts. It's code base is far more mature and proven than any of the current *nix file systems and is better suited to networking than any of the current *nix systems.

The comparisons are here http://en.wikipedia.org/wiki/Comparison_of_file_sy...

The *nix heads that have taken over at Novell have yet to show any kind of reason why it is not being ported. The people that run Novell should be pushing this great FS and porting into SLES.

But of course they won't because they want to kill off everything that came from the big red box.

Yup there goes the baby falling to the concrete with the bathwater. No wonder the stock price is in the tank.

tmstone835's picture

NSS should be a strategic component

Submitted by tmstone835 on 10 August 2010 - 9:03am.

I agree with FlyingGuy about the quality and maturity of NSS. I don't think I can agree with his assessment of why it is not the main file system of future Novell *nix systems. It seems as though the OES people might be hoarding their technology to keep their reason for existence alive. By limiting it to only OES, they can point to their solution as better. Who knows except the Novell insiders. BTRFS looks as though it can be as good as NSS and better in some areas but that is only because NSS has languished and new capabilities are lacking. If Novell had put good R&D into NSS, nothing could touch it.

EXT3 and EXT4 have been thoroughly unimpressive so far. Reiserfs3 is better for most day-to-day things. Reiserfs4 is good but everyone has abandoned it. It eeks out some life but there is not enough momentum to justify its continuation. XFS is impressive until you run into its shortcomings first hand. Of course there are others but none is a clear winner.

FlyingGuy's picture

You may be right

Submitted by FlyingGuy on 10 August 2010 - 10:15am.

Although I don't think it is a case of hording. The OES people have to provide the transition from the NetWare kernel to the Linux kernel and keep all the wheels spinning. The basic problem is that nowhere in the Linux ecosystem does anything with the capabilities of NCP exist and many of those capabilities are built upon the capabilities of NSS.

I think it is more of a culture issue in that *nix heads have always had complete control over their machines and there was never anything like a central file server that controlled access to resources. If they needed something from someone else they just popped over an e-mail and asked for an NFS share and then things moved around. The paradigm of "each machine is a server / workstation" is fine for that type of environment but is completely unsuitable for the basic rank and file employees that do the regular work that happens in corporate America.

Unless Novell has simply decided that this arena is now owned by Microsoft and AD then we need a server that fully supports NSS as the native FS and NCP that provides those same services with the additional capabilities of being able to run the various services that Windows Server 2008 does.

This also means building tools so that people can write those services with the same ease that those services are written for MS boxes. There are MANY MANY RAD tools out there that can do this but none of them is as closely coupled to the target OS as Visual Studio is to the Windows OS.

That coupled with management allowing the development people to write ONE product in a combination of languages like Python, Perl and C or C++ gives developers trying to work on new products nightmares since they have multiple interface styles to deal with when trying to connect to the various services that are provided. Granted almost 100% of the kernel services are C interfaces but when a lot of things boot up you see Perl Loading, Java loading, Python loading and it is just a mess.

I think the biggest problem at Novell is that there are to many Chefs in the kitchen tellign the cooks to implement the same recipes using far different ingredients and while that might be fun and intellectually stimulating for some it is an absolute nightmare for the majority of people trying desperately to keep Novell relevant much less in business.

© 2012 Novell