Re: [gentoo-user] Re: Fragmentation of my drives. Curious mostly

[Dale]

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.

root@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)
root@smoker / #

root@smoker / # /root/fragck.pl /
3.10978840211776% non contiguous files, 1.08156705459019 average fragments.
root@smoker / # /root/fragck.pl /usr/portage/
0.0276657266269232% non contiguous files, 1.00029450612216 average
fragments.
root@smoker / # /root/fragck.pl /boot/
6.25% non contiguous files, 1.0625 average fragments.
root@smoker / # /root/fragck.pl /home/
3.2440588457186% non contiguous files, 1.16408902301018 average fragments.
root@smoker / # /root/fragck.pl /data/
5.56267766568196% non contiguous files, 1.06797837355777 average fragments.
root@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

:-)  :-)