linux-ext4 - Re: [PATCH 01/11 RESEND] libe2p: Add new function get_fragment

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 23 Jun 2011 17:00:17 +0900
From:	Kazuya Mio <k-mio@...jp.nec.com>
To:	"Ted Ts'o" <tytso@....edu>
CC:	ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 01/11 RESEND] libe2p: Add new function get_fragment_score()

2011/06/21 22:56, Ted Ts'o wrote:
> I'm really nervous about having filefrag print a "fragmentation
> score".  The problem is that the problem is invariably far more
> complex than can be boiled into a single number, and so users look at
> it and start worrying when they shouldn't.

It's possible that could happen. I suppose filefrag should output
"fragmented" or "not fragmented" to understand when they shouldn't do e4defag.
But it would be difficult to implement this idea because the threshold for
the determination of which file is fragmented is different of each filesystem.
As it stands now, I think filefrag shouldn't output fragmentation score.

However, I think I add get_fragment_score() to libe2p because e4defrag will
still use it.

> And the statement, "so that e4defrag can compare two files'
> fragmentation to prevent the worse fragmentation" begs the question of
> what is "worse".  The real issue here is that it's a multidimensional
> problem.

We need to define "what is worse" for e4defrag. If fragments per megabyte of
the file is bigger than the threshold, e4defrag will call EXT4_IOC_MOVE_EXT
ioctl. The threshold may be customizable by an option.

> "fragments per megabyte" is definitely better, especially if you
> disregard the tail.  It's worth consider how it works for files
> smaller than a megabyte.  Do you round the file size up to the nearest
> megabyte?  Is it an integer score, or does it need to be floating
> point?  An integer score where the size is rounded up to the nearest
> megabyte sounds like a best plan, but I'm sure we could still find
> some interesting non-linearities that lead to surprising results.

An integer score sounds good to me.

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