* EXT vs XFS at 80% filled filesystem @ 2009-04-30 7:42 Milind Dumbare 2009-04-30 18:34 ` Theodore Tso 0 siblings, 1 reply; 9+ messages in thread From: Milind Dumbare @ 2009-04-30 7:42 UTC (permalink / raw) To: linux-fsdevel; +Cc: xfs 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: EXT vs XFS at 80% filled filesystem 2009-04-30 7:42 EXT vs XFS at 80% filled filesystem Milind Dumbare @ 2009-04-30 18:34 ` Theodore Tso 2009-05-18 13:03 ` Milind 0 siblings, 1 reply; 9+ messages in thread From: Theodore Tso @ 2009-04-30 18:34 UTC (permalink / raw) To: Milind Dumbare; +Cc: linux-fsdevel, xfs 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: EXT vs XFS at 80% filled filesystem 2009-04-30 18:34 ` Theodore Tso @ 2009-05-18 13:03 ` Milind 2009-05-18 13:17 ` Theodore Tso 0 siblings, 1 reply; 9+ messages in thread From: Milind @ 2009-05-18 13:03 UTC (permalink / raw) To: Theodore Tso; +Cc: linux-fsdevel, xfs 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 > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: EXT vs XFS at 80% filled filesystem 2009-05-18 13:03 ` Milind @ 2009-05-18 13:17 ` Theodore Tso 2009-05-20 5:43 ` Milind 0 siblings, 1 reply; 9+ messages in thread From: Theodore Tso @ 2009-05-18 13:17 UTC (permalink / raw) To: Milind; +Cc: linux-fsdevel, xfs 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: EXT vs XFS at 80% filled filesystem 2009-05-18 13:17 ` Theodore Tso @ 2009-05-20 5:43 ` Milind 2009-05-20 10:50 ` Theodore Tso 0 siblings, 1 reply; 9+ messages in thread From: Milind @ 2009-05-20 5:43 UTC (permalink / raw) To: Theodore Tso; +Cc: linux-fsdevel, xfs 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 > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: EXT vs XFS at 80% filled filesystem 2009-05-20 5:43 ` Milind @ 2009-05-20 10:50 ` Theodore Tso 2009-05-20 11:51 ` Milind 2009-05-20 12:46 ` Matthew Wilcox 0 siblings, 2 replies; 9+ messages in thread From: Theodore Tso @ 2009-05-20 10:50 UTC (permalink / raw) To: Milind; +Cc: linux-fsdevel, xfs 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: EXT vs XFS at 80% filled filesystem 2009-05-20 10:50 ` Theodore Tso @ 2009-05-20 11:51 ` Milind 2009-05-20 14:20 ` Theodore Tso 2009-05-20 12:46 ` Matthew Wilcox 1 sibling, 1 reply; 9+ messages in thread From: Milind @ 2009-05-20 11:51 UTC (permalink / raw) To: Theodore Tso; +Cc: linux-fsdevel, xfs 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 > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: EXT vs XFS at 80% filled filesystem 2009-05-20 11:51 ` Milind @ 2009-05-20 14:20 ` Theodore Tso 0 siblings, 0 replies; 9+ messages in thread From: Theodore Tso @ 2009-05-20 14:20 UTC (permalink / raw) To: Milind; +Cc: linux-fsdevel, xfs 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: EXT vs XFS at 80% filled filesystem 2009-05-20 10:50 ` Theodore Tso 2009-05-20 11:51 ` Milind @ 2009-05-20 12:46 ` Matthew Wilcox 1 sibling, 0 replies; 9+ messages in thread From: Matthew Wilcox @ 2009-05-20 12:46 UTC (permalink / raw) To: Theodore Tso; +Cc: Milind, linux-fsdevel, xfs 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." ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-05-20 14:20 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-04-30 7:42 EXT vs XFS at 80% filled filesystem Milind Dumbare 2009-04-30 18:34 ` Theodore Tso 2009-05-18 13:03 ` Milind 2009-05-18 13:17 ` Theodore Tso 2009-05-20 5:43 ` Milind 2009-05-20 10:50 ` Theodore Tso 2009-05-20 11:51 ` Milind 2009-05-20 14:20 ` Theodore Tso 2009-05-20 12:46 ` Matthew Wilcox
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).