You are not logged in.
[root@nightfrost ~]# df | grep shared
/dev/hda4 44G 24G 21G 54% /home/shared
[root@nightfrost ~]# xfs_db -r /dev/hda4
xfs_db> frag
actual 678279, ideal 4674, fragmentation factor 99.31%
xfs_db> quit
[root@nightfrost ~]#
Now, 99.31% fragmentation(!) - what I would need is a defragmentation tool. There is of course a defragmentation tool for xfs in the xfsdump package, but that package is nowhere to be found. A search for xfsdump at the forums here yield three threads; all of which are from 2004. My guess is that very few archers you xfs (hmm... perhaps it's time for a filesystem poll ), and unfortunately my attempts to compile the xfsdump package fail (one of the three threads contain PKGBUILDs even; but I can't compile them). But, hopefully someone does actually use xfs and has a working PKGBUILD for xfsdump... anyone?
Offline
OK; I guess not too many people here do use XFS. Well, I think I'll try to use binary packages from somewhere (debian probably). If that's a bad idea for some reason, please do tell me
Offline
OK; I guess not too many people here do use XFS. Well, I think I'll try to use binary packages from somewhere (debian probably). If that's a bad idea for some reason, please do tell me
I wouldn't use a deb file, unless you're planning on extracting it and installing the files yourself - it should be fine, though it'd probably be best to make a package and stick it in the AUR.
Offline
Yep, I was planning to write a PKGBUILD that grabs precompiled packages, extracts them and creates arch-packages (although the whole process feels kinda ugly). I'll be playing around with the sources some more, and I'll post the PKGBUILD if I ever get them working.
However, I do believe xfsdump belongs in current...
Offline
However, I do believe xfsdump belongs in current...
Yeah, probably - but you have to keep in mind the arch repos are not based on which packages "deserve" to be in each repo, but they're based on need... obviously if you're the only person in all of the Arch community who uses XFS, then there's not much of a need, is there?
That said, it's probably not that big of a deal to put into extra (probably not worth putting into current)
Offline
but they're based on need... obviously if you're the only person in all of the Arch community who uses XFS, then there's not much of a need, is there?
Yep, precisely; and that's where abs comes in the picture and makes life easy for people like me who have esoteric needs 99% of the time that works, but when I can't compile the packages myself, I curse my inability and get annoyed.
Anyway, the reason I suggested xfsdump to be in current is because xfsprogs is in current. As far as I understand, those two packages should actually be one. The reason why they aren't is (if I remember correctly) not based on anything reasonable, but has just stuck due to reasons that are no longer applicable.
Anyway, if anybody knows why this happens, I'd love to know
=== include ===
rm -f attr
ln -s . attr
=== libmisc ===
/usr/bin/libtool --mode=compile ccache gcc -march=pentium-m -O2 -pipe -fomit-frame-pointer -g -DDEBUG -funsigned-char -fno-strict-aliasing -Wall -DVERSION="2.4.23" -DLOCALEDIR="/usr/share/locale" -DPACKAGE="attr" -I./include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -g -DDEBUG -funsigned-char -fno-strict-aliasing -Wall -DVERSION="2.4.23" -DLOCALEDIR="/usr/share/locale" -DPACKAGE="attr" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -c quote.c
libtool: compile: unable to infer tagged configuration
libtool: compile: specify a tag with `--tag'
make[1]: *** [quote.lo] Error 1
make: *** [default] Error 2
The PKGBUILD is to be found on these forums. It was posted over a year ago I think, so I've just changed the version number...
# $Id $
# Contributor: zeldan <zeldan@email.it>
pkgname=xfs_attr
pkgver=2.4.23
pkgrel=1
pkgdesc="XFS filesystem utilities"
url="http://oss.sgi.com/projects/xfs/"
depends=('glibc')
source=(ftp://oss.sgi.com/projects/xfs/cmd_tars/attr-$pkgver.src.tar.gz)
build() {
cd $startdir/src/attr-$pkgver
./configure --prefix=/usr
make || return 1
make DESTDIR=$startdir/pkg install install-lib
rm -rf $startdir/pkg/usr/man/man2 $startdir/pkg/usr/share
ln -sf --target-directory=$startdir/pkg/usr/lib ../libexec/libattr.a
ln -sf --target-directory=$startdir/pkg/usr/lib ../libexec/libattr.la
ln -sf --target-directory=$startdir/pkg/usr/libexec ../lib/libattr.so
}
Offline
Anyway, the reason I suggested xfsdump to be in current is because xfsprogs is in current. As far as I understand, those two packages should actually be one. The reason why they aren't is (if I remember correctly) not based on anything reasonable, but has just stuck due to reasons that are no longer applicable.
Ahhh... didn't know xfsprogs was in current... I'll second your motion then 8)
If I get a chance and am bored, I'll take a look at it and try to get it built.
Offline
Ahhh... didn't know xfsprogs was in current... I'll second your motion then 8)
Thanks
If I get a chance and am bored, I'll take a look at it and try to get it built.
Cool. Thanks. It's not like I'm in a hurry to get it going really. I can always use Knoppix disc to get my dirty job done ...And for some reason that XFS partition is still blazingly fast, although it says it's 99& fragmented...
Offline
Hmmm ithis builds fine on my system:
pkgname=xfs-attr
pkgver=2.4.23
pkgrel=1
pkgdesc="XFS filesystem utilities"
url="http://oss.sgi.com/projects/xfs/"
depends=('glibc')
source=(ftp://oss.sgi.com/projects/xfs/cmd_tars/attr-$pkgver.src.tar.gz)
build() {
cd $startdir/src/attr-$pkgver
#this is crappy... non-relocatable install
./configure --prefix=$startdir/pkg/usr
sed -i "s@PKG_LOCALE_DIRs*=s*${prefix}@PKG_LOCALE_DIR = /usr@"
include/builddefs
make || return 1
make install install-lib
}
Offline
Hmmm... strange; I get the same error as above :?
Curious about your make install line. It doesn't contain DESTDIR. Will it install in pkg/ anyway?
Thanks for the PKGBUILD though. Now that I know it works somewhere else, I can look elsewhere to solve my problems...
Offline
Hmmm... strange; I get the same error as above :?
Curious about your make install line. It doesn't contain DESTDIR. Will it install in pkg/ anyway?
Thanks for the PKGBUILD though. Now that I know it works somewhere else, I can look elsewhere to solve my problems...
Yeah, if you look at the comment, they don't provide a relocatable install... that is, the don't honor DESTDIR. Running the PKGBUILD provided above, it attempts to install in /usr/ (the --prefix setting).
So, what I had to do was set the --prefix to where it was actually installing to ($startdir/pkg/usr) and then scan through the Makfiles to see if that's going to affect anything else. The only thing it affected was the "LOCALE_DIR", which is the reason for the sed line (I had to force the local to the proper place in /usr/share/locale)
------------------------
About the build - are you using packages from testing?
Offline
I'm not having much luck with this... I haven't been able to compile any of this. I can't get past the error I've posted. So my question now is; to whom do I propose to include xfsdump in the official arch repos?
(Although, I think I'm gonna switch from XFS to something else (reiser4?) - the drive is starting to feel it's 99% fragmented. I think it's Azureus that constantly runs on that drive that fragments it that badly. Still, I think xfsdump is a good idea to have in the official repos if indeed archlinux has support for xfs).
Offline
Reiser3.6 can get fragmented, after a fashion, though I can't really see a partition getting fragmented that badly. :shock: Not sure about Reiser4 though.
(Is Reiser4 supported by the current 2.6 kernel?)
Offline
Yeah, as far as I understand XFS has that pecularity that it actually can get rather fragmented. For that reason, I guess, they developed a defragmentation tool. I'm using reiser4 on some partitions (I use the archck patch). The thing is, though, reiser3- and reiser4-disks both take a considerably longer time to mount for some reason. That's why I originally moved over to XFS. I have an external 100G disk which takes ca 10 seconds to get mounted (I guess it's the journal replay) when it's reiser, and less than a second when it's xfs.
All that said. I can't really think how any filesystem would evade fragmentation with a bittorrent client running...
Offline
Eh? I have 2 drives, both 40 gigs - the master has 2 reiserfs partitions and the slave is a single huge one. Everything mounts in a single second.
Offline
Hmm strange... I did start a thread about this over at linuxquestions.org over a year ago when I first started using linux and there was only one other person who replied to say that he experienced the same. Anyway, over a year later now and several distributions behind me, I still have the same thing. When a reiser partition gets mounted, it takes a noticeably longer time than XFS.
Maybe there's something about the mount options. I use notail,noatime and then probably just defaults. Do you have anything interesting there?
(also, it could be that slowdown is mostly noticeable with >100G).
Offline
Well, you should probably not use notail. People say it speeds things up, but I have never noticed any significant speed increase from it, and IIRC it can cause your drive to get "fragmented" (as far as ReiserFS can get fragmented) eventually.
Offline
OK, I'll keep that in mind; thanks. I guess it's just the noatime option that's important, especially since I'm on a laptop.
I'll post back if I notice it mounts faster, but it's gonna take some time for me to transfer from xfs to reiser4 - I need to back my stuff up somehow...
Offline
How do you check the fragmentation on the various filesystems including but not limited too XFS, if you can a tall that is?
Offline
That's a good question. I'd like an answer to that as well. For XFS, check out the first post of this thread. For other filesystems, I don't have a clue.
Offline
That's a good question. I'd like an answer to that as well. For XFS, check out the first post of this thread. For other filesystems, I don't have a clue.
ryan@dogma ~ $ xfs_db -r /dev/hdb1
xfs_db> frag
xfs_db: out of memory
Offline
Well, it seems like something fishy is happening to the xfsprogs package. Most of us are getting segfaults, but there's been a bugreport so let's see what happens...
Offline