Nikos Chantziaras wrote: > Dale wrote: >> Nikos Chantziaras wrote: >>> OK, I once again verified that fragmentation seems to be a big issue >>> even on Linux. I just migrated to ext4, and in order to do that I had >>> to rsync, format and rsync back. The result is similar to the last >>> time I did this (over 8 months ago): >>> >>> emerge --sync takes 15 seconds (at least 3 minutes yesterday) >>> update-eix takes 2 seconds (20 seconds yesterday) >>> >>> And I don't believe it's due to ext4. It's a nice speed-up from ext3, >>> but not THAT nice. >> >> Well, try as I may, I could not get mine past 10% on resiserfs. >> Fragmentation happens on any file system but I think the point is that >> Linux doesn't get as bad as the windoze file system. 10% or so is not >> to bad depending on the size of the files. Files that are large will >> have to be fragmented no matter what file system you use. >> I posted in another the reply right after a copy to another drive. I >> think that was before I even booted into the OS and was still on the >> CD. It is around 2% or so. I doubt given that condition that it could >> get any better. > > I think the main problem may not be so much fragmentation of files, > but rather their position on disk. Even if files are not fragmented, > if they are located too far from each other even though they're > related (same directory for example) or there's simply too much empty > space between files (I think this is intentional in order to reduce > fragmentation) then seek times get really bad. After I rsync the data > back, it's nicely and sequentially laid out on disk. I guess over > time it starts to get further apart again (to combat fragmentation) > and emerge --sync goes up from 15 seconds to 2 minutes again. Even > though the files aren't fragmented at all. > > Some defrag apps for Windoze actually offer to put the files back > closer together without trying to defragment at all. I guess this is > why :P > > >
Well, this is what I got on my rig. Sort of interesting in a way. r...@smoker / # mount /dev/hda6 on / type reiserfs (rw) /proc on /proc type proc (rw) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec) udev on /dev type tmpfs (rw,nosuid) devpts on /dev/pts type devpts (rw,nosuid,noexec) /dev/hda1 on /boot type ext2 (rw) /dev/hda7 on /home type reiserfs (rw) /dev/hda8 on /usr/portage type ext2 (rw) /dev/hda9 on /data type reiserfs (rw) none on /dev/shm type tmpfs (rw) usbfs on /proc/bus/usb type usbfs (rw,noexec,nosuid,devmode=0664,devgid=85) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) /dev/hdd on /media/hdd type udf (rw,noexec,nosuid,nodev,uid=0,gid=0,umask=007) r...@smoker / # r...@smoker / # /root/fragck.pl / 3.10978840211776% non contiguous files, 1.08156705459019 average fragments. r...@smoker / # /root/fragck.pl /usr/portage/ 0.0276657266269232% non contiguous files, 1.00029450612216 average fragments. r...@smoker / # /root/fragck.pl /boot/ 6.25% non contiguous files, 1.0625 average fragments. r...@smoker / # /root/fragck.pl /home/ 3.2440588457186% non contiguous files, 1.16408902301018 average fragments. r...@smoker / # /root/fragck.pl /data/ 5.56267766568196% non contiguous files, 1.06797837355777 average fragments. r...@smoker / # Now keep in mind that the first one includes all the others. I'm logged into a GUI so I can't umount /home at least. May do that in single mode someday. I think sometimes the files are just to big to fit on one section. I know I have some files that are pretty big. I got a couple videos that are big that came off my camera and one video that is a hour or so long. I think there are a lot of variables that without a microscope we can never see and know for sure. Dale :-) :-)
