EXT vs XFS at 80% filled filesystem

EXT vs XFS at 80% filled filesystem

[Milind Dumbare]

Hi,

I have heard of XFS's performance is not good as compared to EXT3 when 
the filesystem(disk) is 80% filled with data. Is it true? I have went 
through lots of performance documents of both XFS and EXT3 but could not 
find such performance benchmarking (for 80% full filesystems).

Any numbers or pointers to other documents are appreciated.

Thanks
-Miline

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: EXT vs XFS at 80% filled filesystem

[Theodore Tso]

On Thu, Apr 30, 2009 at 01:12:22PM +0530, Milind Dumbare wrote:
> Hi,
>
> I have heard of XFS's performance is not good as compared to EXT3 when  
> the filesystem(disk) is 80% filled with data. Is it true? I have went  
> through lots of performance documents of both XFS and EXT3 but could not  
> find such performance benchmarking (for 80% full filesystems).

I've not heard of any such performance metrics, and I suspect it would
very much depend on how the filesystem was "aged".  A filesystem that
has been in use for a few years and is at 80% capacity will behave
very different from a brand-new filesystem which was freshly formatted
and then filled with a few large files until said filesystem was 80%
full.

							- Ted

Re: EXT vs XFS at 80% filled filesystem

[Milind]

Hi Theodore,

I am facing some weird problem of cross compiling libuuid sources. I
downloaded e2fsprogs and cross-compiled them but when I do "make
install-libs" it doesn't really install libuuid.so but installs
libuuid.a.

Can I have some pointers to build libuuid.so to have it in my toolchain
libraries.

I have crawled through web but couldn't get any nice solution to this.

Thanks in Advance
-Miline

On Thu, 2009-04-30 at 14:34 -0400, Theodore Tso wrote:
> On Thu, Apr 30, 2009 at 01:12:22PM +0530, Milind Dumbare wrote:
> > Hi,
> >
> > I have heard of XFS's performance is not good as compared to EXT3 when  
> > the filesystem(disk) is 80% filled with data. Is it true? I have went  
> > through lots of performance documents of both XFS and EXT3 but could not  
> > find such performance benchmarking (for 80% full filesystems).
> 
> I've not heard of any such performance metrics, and I suspect it would
> very much depend on how the filesystem was "aged".  A filesystem that
> has been in use for a few years and is at 80% capacity will behave
> very different from a brand-new filesystem which was freshly formatted
> and then filled with a few large files until said filesystem was 80%
> full.
> 
> 							- Ted
> 

Re: EXT vs XFS at 80% filled filesystem

[Theodore Tso]

On Mon, May 18, 2009 at 06:33:28PM +0530, Milind wrote:
> Hi Theodore,
> 
> I am facing some weird problem of cross compiling libuuid sources. I
> downloaded e2fsprogs and cross-compiled them but when I do "make
> install-libs" it doesn't really install libuuid.so but installs
> libuuid.a.

The "make install" taret is designed to install what is needed to run
the e2fsprogs programs, including shared libraries; "make
install-libs" is designed to install what as needed for development
purpoes.

So running "make install" in the lib/uuid" should do what you want.

   	   	 	     	 	   	  - Ted

Re: EXT vs XFS at 80% filled filesystem

[Milind]

I am building xfsprogs to add it to my toolchain and want xfsprogs to
refer to my toolchain's libuuid. So I need libuuid.so in my toolchain.
But building e2fsprogs from sources doesn't build libuuid as .so (builds
as .a). Could you please give some pointers on building libuuid as .so?

Do I have to change Makefiles? How do you do it for ubuntu/debian
packages that you maintain?

Thanks in advance
-Miline

On Mon, 2009-05-18 at 09:17 -0400, Theodore Tso wrote:
> On Mon, May 18, 2009 at 06:33:28PM +0530, Milind wrote:
> > Hi Theodore,
> > 
> > I am facing some weird problem of cross compiling libuuid sources. I
> > downloaded e2fsprogs and cross-compiled them but when I do "make
> > install-libs" it doesn't really install libuuid.so but installs
> > libuuid.a.
> 
> The "make install" taret is designed to install what is needed to run
> the e2fsprogs programs, including shared libraries; "make
> install-libs" is designed to install what as needed for development
> purpoes.
> 
> So running "make install" in the lib/uuid" should do what you want.
> 
>    	   	 	     	 	   	  - Ted
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

Re: EXT vs XFS at 80% filled filesystem

[Theodore Tso]

On Wed, May 20, 2009 at 11:13:30AM +0530, Milind wrote:
> I am building xfsprogs to add it to my toolchain and want xfsprogs to
> refer to my toolchain's libuuid. So I need libuuid.so in my toolchain.
> But building e2fsprogs from sources doesn't build libuuid as .so (builds
> as .a). Could you please give some pointers on building libuuid as .so?

Add to the configure script --enable-elf-shared (I assume this is on a
Linux system, right?).  There are a number of configure options.  Run
configure --help to see them....

> Do I have to change Makefiles? How do you do it for ubuntu/debian
> packages that you maintain?

The debian packages are built using the standard debian packaging
framework, which means a number of support programs, one of which
eventually runs "make -f debian/rules" with various makefile targets.
Take a look at it, but be warned it's rather complicated.

The debian packages ultimately end up building e2fsprogs three times,
with different sets of configure options.  One is the standard build,
one is for the restricted-size build for boot floppies (which arguably
we don't need any more since we these days CD-ROM's have plenty of
space, and Debian doesn't support boot floppies any more) and one is
for the static build for e2fsck.static (although the utility of that
one is somewhat dubious given that even the shell is with shared
library, so if the filesystem is corrupted enough that shared libaries
don't work, it's rescue CD-ROM time; the main use for e2fsck.static is
for emergency use when someone running an older version of Debian
needs a newer e2fsck to fix a filesystem corruption).

      	      	     	      		 - Ted

Re: EXT vs XFS at 80% filled filesystem

[Milind]

Thanks Theodore,
It worked.

I have one question regarding building libuuid.so

$/usr/bin/ldd lib/libuuid.so.1.2 shows
linux-vdso.so.1 =>  (0x00007fff075fe000)
libc.so.6=> /home/miline/toolchain/x86_64-unknown-linux-gnu/glibc-2.7/lib/libc.so.6 (0x00007faafef52000)
/lib64/ld-linux-x86-64.so.2 (0x00007faaff4a3000)

my CFLAGS are
CFLAGS=-Wl,--dynamic-linker,/home/miline/toolchain/x86_64-unknown-linux-gnu/glibc-2.7/lib/ld-linux-x86-64.so.2,--rpath,/home/miline/toolchain/x86_64-unknown-linux-gnu/glibc-2.7/lib/

libuuid.so is supposed to have dependancy
on /home/miline/toolchain/x86_64-unknown-linux-gnu/glibc-2.7/lib/ld-linux-x86-64.so.2 (third entry in ldd output) right? And not on /lib64/ld-linux-x86-64.so.2

I tried modifying as follows but didn't really work. Any comments?

lib/uuid/Makefile:321

- @(cd elfshared; $(CC) --shared -o $(ELF_LIB) $(LDFLAGS) \
+ @(cd elfshared; $(CC) --shared -o $(ELF_LIB) $(CFLAGS) $(LDFLAGS) \
      -Wl,-soname,$(ELF_SONAME) $(OBJS) $(ELF_OTHER_LIBS))


I have seen this problem in xfsprogs package too, should post the fix
in new thread.

-Miline


On Wed, 2009-05-20 at 06:50 -0400, Theodore Tso wrote:
> On Wed, May 20, 2009 at 11:13:30AM +0530, Milind wrote:
> > I am building xfsprogs to add it to my toolchain and want xfsprogs to
> > refer to my toolchain's libuuid. So I need libuuid.so in my toolchain.
> > But building e2fsprogs from sources doesn't build libuuid as .so (builds
> > as .a). Could you please give some pointers on building libuuid as .so?
> 
> Add to the configure script --enable-elf-shared (I assume this is on a
> Linux system, right?).  There are a number of configure options.  Run
> configure --help to see them....
> 
> > Do I have to change Makefiles? How do you do it for ubuntu/debian
> > packages that you maintain?
> 
> The debian packages are built using the standard debian packaging
> framework, which means a number of support programs, one of which
> eventually runs "make -f debian/rules" with various makefile targets.
> Take a look at it, but be warned it's rather complicated.
> 
> The debian packages ultimately end up building e2fsprogs three times,
> with different sets of configure options.  One is the standard build,
> one is for the restricted-size build for boot floppies (which arguably
> we don't need any more since we these days CD-ROM's have plenty of
> space, and Debian doesn't support boot floppies any more) and one is
> for the static build for e2fsck.static (although the utility of that
> one is somewhat dubious given that even the shell is with shared
> library, so if the filesystem is corrupted enough that shared libaries
> don't work, it's rescue CD-ROM time; the main use for e2fsck.static is
> for emergency use when someone running an older version of Debian
> needs a newer e2fsck to fix a filesystem corruption).
> 
>       	      	     	      		 - Ted
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

Re: EXT vs XFS at 80% filled filesystem

[Matthew Wilcox]

On Wed, May 20, 2009 at 06:50:11AM -0400, Theodore Tso wrote:
> The debian packages ultimately end up building e2fsprogs three times,
> with different sets of configure options.  One is the standard build,
> one is for the restricted-size build for boot floppies (which arguably
> we don't need any more since we these days CD-ROM's have plenty of
> space, and Debian doesn't support boot floppies any more) and one is
> for the static build for e2fsck.static (although the utility of that
> one is somewhat dubious given that even the shell is with shared
> library, so if the filesystem is corrupted enough that shared libaries
> don't work, it's rescue CD-ROM time; the main use for e2fsck.static is
> for emergency use when someone running an older version of Debian
> needs a newer e2fsck to fix a filesystem corruption).

If you install sash, you really do get a statically linked shell:

$ ldd /bin/sash 
ldd: exited with unknown exit code (126)
$ file /bin/sash 
/bin/sash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.8, stripped

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: EXT vs XFS at 80% filled filesystem

[Theodore Tso]

On Wed, May 20, 2009 at 05:21:14PM +0530, Milind wrote:
> my CFLAGS are
> CFLAGS=-Wl,--dynamic-linker,/home/miline/toolchain/x86_64-unknown-linux-gnu/glibc-2.7/lib/ld-linux-x86-64.so.2,--rpath,/home/miline/toolchain/x86_64-unknown-linux-gnu/glibc-2.7/lib/
> 
> libuuid.so is supposed to have dependancy
> on /home/miline/toolchain/x86_64-unknown-linux-gnu/glibc-2.7/lib/ld-linux-x86-64.so.2 (third entry in ldd output) right? And not on /lib64/ld-linux-x86-64.so.2
> 
> I tried modifying as follows but didn't really work. Any comments?
> 

I suggest you read the man page for "ld", in particular for the option
--rpath-link....

						- Ted