Re: Problems with e4defrag -c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2011/01/08 4:38, Ted Ts'o wrote:
If we do it that way, I'm not sure we really need to have access to
the superblock to get various file system values. I can imagine requesting
certain parameters --- if you have root access, you can grab the superblock
and adjust the "threshold of perfection" down from 256MB to 32MB
if flex_bg is not enabled, or based on the size of the flex_bg groups. But if
you don't have access, it might be smarter just to use some default
"threshold of perfection", as opposed to having lots of "do we have root"
checks sprinkled all over the program.

I agree to use some default "threshold of perfection". In this case, 256MB is
too big because all files will get the worst score if flex_bg is disabled.
So I think "blocks_per_group - 2048" seems to be good threshold. 2048 means
the maximum block region of mballoc with the exception of more than
8KB blocksize. If we try to allocate the contiguous blocks including some
metadata blocks (backup of the superblock, blockgroup descriptor, etc.),
this threshold will judge that there is no fragmentation in the file.

e.g. Allocate 512MB contiguous blocks including some metadata blocks

# dd if=/dev/zero of=/mnt/mp1/file bs=1M count=512 oflag=sync
# filefrag -v /mnt/mp1/file
Filesystem type is: ef53
File size of /mnt/mp1/file is 536870912 (131072 blocks, blocksize 4096)
 ext logical physical expected length flags
   0       0    33280           30720
   1   30720    65536    63999  32768
   2   63488   100352    98303  32768
   3   96256   133120           30720
   4  126976   165888   163839   4096 eof

Hmm, maybe the right answer is that we have a single function, located
in libe2p, that calculates the "fragmentation score". We can separate that
out from the e4defrag code, and make it be a library function. The programs
that want to use it can call that library function. (Parameters to the
fragmentation score, such as the "threshold of perfection", would be passed
into the library function, along with a file descriptor to the file so that
FIEMAP could be called on that file.)

OK. I'll create the new file "fragment_score.c" into lib/e2p and add
a function to this file. We can get the percent of the small extents in the
target file by calling this function.

I'm not sure how useful it is to do a recursive tree walk just to display
the information for all the files in the directory. Filefrag will already
take a list of files on the command-line, and if you want to do a recursive
tree walk, you can do a "find /path/to/dir -type f | xargs filefrag".

It's true that we should use find command if we really want to know
the fragmentation scores of all of the files in the directory.
I won't add a recursive tree walk to filefrag.

Regards,
Kazuya Mio
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux