ext4 - 52.2% non-contiguous

[Daryl Styrk]

I'm trying to understand what is causing fsck to report /dev/sda4 being
highly fragmented.  The filesystem is only a couple days old.  I created
the it with mke2fs -t ext4.

After initially building the filesystem I ran fsck which showed something
like 0.7% if I remember correctly.  I then copied about 60GB from an ext3
via rsync after which the fragmentation showed up.  

I'm running Sid, 2.6.30-1-amd64 and have e2fsprogs 1.41.7-1.

Here is the snippet after a forced fsck on reboot.

Mon Jul  6 17:43:17 2009: Activating swap...done.
Mon Jul  6 17:43:17 2009: Checking root file system...fsck 1.41.7 (29-June-2009)
Mon Jul  6 17:43:17 2009: \002/dev/sda3: 141728/917504 files (0.2% non-contiguous), 774394/3664828 blocks      
Mon Jul  6 17:43:17 2009: done.
Mon Jul  6 17:43:17 2009: Setting the system clock.
Mon Jul  6 17:43:18 2009: Cleaning up ifupdown....
Mon Jul  6 17:43:18 2009: Loading kernel modules...done.
Mon Jul  6 17:43:18 2009: Checking file systems...fsck 1.41.7 (29-June-2009)
Mon Jul  6 17:43:18 2009: \002/dev/sda1: 28/26104 files (7.1% non-contiguous), 24372/104388 blocks              
Mon Jul  6 17:43:19 2009: \002/dev/sda4: 16776/14278656 files (52.2% non-contiguous), 20261557/57111075 blocks  
Mon Jul  6 17:43:30 2009: done.


This is a snippet from e2fsck -fpDC0 -E fragcheck /dev/sda4 the full
7000 lines are here http://pastebin.com/f62a00b8c


2490449: expecting 10078208 actual extent phys 10140672 log 1024 len 107
2490449: expecting 10140779 actual extent phys 22521929 log 1131 len 10
2490450: expecting 10076160 actual extent phys 10078208 log 512 len 48
2490451: expecting 10079232 actual extent phys 10138112 log 512 len 454
2490452: expecting 10079744 actual extent phys 10139136 log 512 len 38
2490453: expecting 10081280 actual extent phys 10141696 log 1024 len 365
2490455: expecting 10082304 actual extent phys 10143744 log 1024 len 288
2490457: expecting 10084352 actual extent phys 10144768 log 1024 len 251
2490460: expecting 10086400 actual extent phys 10145792 log 1024 len 166
2490462: expecting 10087424 actual extent phys 10146816 log 1



Are there other checks I should/can perform?  Should I have formatted the
filesystem a different way?  I followed the guide at
http://ext4.wiki.kernel.org/index.php/Ext4_Howto .  This is not a
production system and needing to reformat is no big deal.
 

I googled around a bit only finding one post with fsck reporting over 100%
non contiguous.  Could this be a bug?

Ideas?

--
Daryl Styrk
Naples FL, USA


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Perkins, Jerry-2]

Daryl Styrk wrote:
> I'm trying to understand what is causing fsck to report /dev/sda4 being
> highly fragmented.  The filesystem is only a couple days old.  I created
> the it with mke2fs -t ext4.
>
> After initially building the filesystem I ran fsck which showed something
> like 0.7% if I remember correctly.  I then copied about 60GB from an ext3
> via rsync after which the fragmentation showed up.  
>
> I'm running Sid, 2.6.30-1-amd64 and have e2fsprogs 1.41.7-1.   <snip>

    Just an uneducated guess.   rsync created the entire structure with
empty files.   Then populated the files.
    I had to copy files once from one box to another.  It creates a
list, then moves the files individually.   This is the only way to
maintain permissions from one box to another.
    Here is the script that I used:

#! /bin/bash
#
# To copy files to another computer retaining owner / group.
#
# --------- CONFIGURE SECTION ----------
#
#    Your User name on the Server.  Normally should be
# the same as your Computer User Name.
REMOTEUSERNAME="root"
#
#   Remote IP Address.
REMOTEIP="192.168.15.209"
#
# 0 - Test
BACKUPLIST="/home/m* /usr/local/bin"
#
# 1 - home
# BACKUPLIST="/home"
#
# 2 - Samba
# BACKUPLIST="/srv/samba"
#
# 3 - MySQL
# BACKUPLIST="/var/lib/mysql/m* /var/lib/mysql/n* /var/lib/mysql/t*
/var/lib/mysql/w*"
#
# 4 - WWW
# BACKUPLIST="/srv/www"
#
# 5 - /usr/local
# BACKUPLIST="/usr/local/bin /var/local"
#
# Noye, run as root
# --------- NO EDITING BELOW THIS LINE ----------
#
for LIST in $BACKUPLIST
do
   echo " "
   echo "Starting $LIST"
   tar -zcpf - $LIST | ssh $REMOTEUSERNAME@$REMOTEIP "cd /;sudo tar -zxpf -"
   echo "finished"
done


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Todd A. Jacobs]

On Mon, Jul 06, 2009 at 06:49:09PM -0400, Daryl Styrk wrote:

> After initially building the filesystem I ran fsck which showed
> something like 0.7% if I remember correctly.  I then copied about 60GB
> from an ext3 via rsync after which the fragmentation showed up.  

by default, rsync copies a file in small chunks, so copying an entire
filesystem to a drive that is actively in use could certainly cause
fragmentation. If you have to use rsync, and have enough space for the
tar file on the remote side, you can try something like this:

    tar cvf - /home | rsync -PSauve ssh - host:/path/to/copied/tarfile

AFAIK, you'd have to do some real gymnastics with named pipes or process
substitution to treat an rsync transfer as a pipeline to untarring, so
I'd suggest this instead:

    # From the root directory of the host on which you want to unpack
    # the copied filesystem.
    ssh -c 'sudo tar cvSf - /home' remote | sudo tar xvSpf -

Really, the main reasons to use rsync are:

    - to enable resume on really large files (e.g. an entire filesystem
      tarred as home.tar.gz)
    - to transfer file deltas rather than entire files

For what you're doing, I don't think rsync is the right tool unless
you're trying to copy home.tar.gz over an unreliable network connection.
If it's on a LAN, just use SSH and tar.

--
"Oh, look: rocks!"
        -- Doctor Who, "Destiny of the Daleks"


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Miles Bader-2]

"Todd A. Jacobs" <nospam@...> writes:
> by default, rsync copies a file in small chunks, so copying an entire
> filesystem to a drive that is actively in use could certainly cause
> fragmentation.

Actually shouldn't ext4 do _better_ (than ext3 etc) in such a case,
since it does allocate-on-write, allowing it to allocate contiguous
storage despite the user writes being small?

> Really, the main reasons to use rsync are:
>
>     - to enable resume on really large files (e.g. an entire filesystem
>       tarred as home.tar.gz)
>     - to transfer file deltas rather than entire files

While there's some truth to that, I think people often like to use rsync
even for virgin copies simply because it has a very convenient syntax,
and it's simpler to use one tool for all cases (new copies, "update"
copies, resumes, etc) and not have to worry about micro-optimizing each
individual case.

-Miles

--
Friendless, adj. Having no favors to bestow. Destitute of fortune. Addicted to
utterance of truth and common sense.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Miles Bader-2]

Miles Bader <miles@...> writes:
> Actually shouldn't ext4 do _better_ (than ext3 etc) in such a case,
> since it does allocate-on-write, allowing it to allocate contiguous
> storage despite the user writes being small?

btw, I meant allocate-on-write-to-the-disk, aka delayed allocation...

-Miles

--
Quotation, n. The act of repeating erroneously the words of another. The words
erroneously repeated.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Todd A. Jacobs]

On Fri, Jul 10, 2009 at 02:29:10PM +0900, Miles Bader wrote:

> Actually shouldn't ext4 do _better_ (than ext3 etc) in such a case,
> since it does allocate-on-write, allowing it to allocate contiguous
> storage despite the user writes being small?

Depends. If an application doesn't pre-allocate space on the filesystem
for each file, then extents aren't going to help much. I don't know if
rsync pre-allocates or not, but your experience indicates "not."

In order to pre-allocate, the file system would need to know the file
size to allocate before opening a file handle for write; this obviously
wouldn't work well if writing from a stream or a rolling merge like
rsync.

If you're hell-bent on using rsync, you might try the --whole-file
option, and see if that helps. I'd be curious to know the answer to that
myself.

--
"Oh, look: rocks!"
        -- Doctor Who, "Destiny of the Daleks"


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...