| 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
| ||
|
Message-Id: <1359527713.648.140661184334613.06CF38D4@webmail.messagingengine.com>
Date: Wed, 30 Jan 2013 17:35:13 +1100
From: Bron Gondwana <brong@...tmail.fm>
To: Eric Sandeen <sandeen@...hat.com>
Cc: linux-ext4@...r.kernel.org, Rob Mueller <robm@...tmail.fm>
Subject: Re: fallocate creating fragmented files
On Wed, Jan 30, 2013, at 05:05 PM, Eric Sandeen wrote:
> On 1/29/13 11:46 PM, Bron Gondwana wrote:
> > Hi All,
> >
> > I'm trying to understand why my ext4 filesystem is creating highly fragmented files even though it's only just over 50% full.
>
> It's at least possible that freespace is very fragmented; you could try the "e2freefrag" command to see.
[brong@...p14 ~]$ e2freefrag /dev/md0
Device: /dev/md0
Blocksize: 1024 bytes
Total blocks: 62522624
Free blocks: 26483551 (42.4%)
Min. free extent: 1 KB
Max. free extent: 757 KB
Avg. free extent: 14 KB
Num. free extent: 1940838
HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range : Free extents Free Blocks Percent
1K... 2K- : 538480 538480 2.03%
2K... 4K- : 362189 870860 3.29%
4K... 8K- : 321158 1681591 6.35%
8K... 16K- : 268848 2934959 11.08%
16K... 32K- : 210746 4697440 17.74%
32K... 64K- : 151755 6738418 25.44%
64K... 128K- : 63761 5512870 20.82%
128K... 256K- : 20563 3552580 13.41%
256K... 512K- : 3308 1047995 3.96%
512K... 1024K- : 30 17615 0.07%
> > Now looking at the verbose output, we can see that there are many extents of just 3 or 4 blocks:
> >
> > [brong@...p14 conf]$ filefrag -v testfile | awk '{print $5}' | sort -n | uniq -c | head
> > 2
> > 1 is
> > 1 length
> > 1 unwritten
> > 6 3
> > 10 4
> > 6 5
> > 5 6
> > 3 7
> > 1 8
>
> But longer extents too, right:
>
> $ filefrag -v testfile | awk '{print $5}' | sort -n | uniq -c | tail
> 1 162
> 1 164
> 1 179
> 1 188
> 1 215
> 1 231
> 1 233
> 1 255
> 1 322
> 1 357
>
> > Yet looking at the next file,
> >
> > [brong@...p14 conf]$ filefrag -v testfile2 | awk '{print $5}' | sort -n | uniq -c | tail
> > 1 173
> > 1 175
> > 1 178
> > 1 184
> > 1 187
> > 1 189
> > 1 194
> > 1 289
> > 1 321
> > 1 330
> >
>
> and presumably shorter extents at the beginning?
Well, that's sorted. Yes, there were shorter extents too.
> So it sounds like both files are a mix of long & short extents.
Definitely.
> > There are multiple extents of hundreds of blocks in length. Why weren't they used in allocating the first file?
>
> I'm not sure, offhand. But just to be clear, while contiguous allocations are usually a nice side-effect of fallocate, nothing at all guarantees it. It only guarantees that you'll have that space available for future writes.
Sure. I was hoping it would help though!
> Still, it'd be interesting to figure out why the allocator is behaving this way.
> It'd be interesting to see the freefrag info, the allocator might really be in scavenger mode.
What do you think from the output above. Is that reasonable? I'll check a more recently set-up machine.
[brong@...p30 ~]$ e2freefrag /dev/sdf1
Device: /dev/sdf1
Blocksize: 1024 bytes
Total blocks: 97124320
Free blocks: 68429391 (70.5%)
Min. free extent: 1 KB
Max. free extent: 1009 KB
Avg. free extent: 25 KB
Num. free extent: 2781696
HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range : Free extents Free Blocks Percent
1K... 2K- : 705257 705257 1.03%
2K... 4K- : 553577 1348712 1.97%
4K... 8K- : 349406 1789755 2.62%
8K... 16K- : 289102 3185026 4.65%
16K... 32K- : 279061 6307452 9.22%
32K... 64K- : 271631 12321046 18.01%
64K... 128K- : 205191 18340308 26.80%
128K... 256K- : 110082 19121199 27.94%
256K... 512K- : 16962 5584384 8.16%
512K... 1024K- : 1427 882388 1.29%
This one is 100Gb SSDs from some other vendor (can't remember which) on hardware RAID1. It's never been more than about 30% full. It looks like a similar histogram of extent sizes. Again it's a 1kb block size (piles of small files on these filesystems)
[brong@...p30 ~]$ dumpe2fs -h /dev/sdf1
dumpe2fs 1.42.4 (12-Jun-2012)
Filesystem volume name: ssd30
Last mounted on: /mnt/ssd30
Filesystem UUID: c2623b6a-b3f4-4a5a-99e3-495f29112ba6
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 12140544
Block count: 97124320
Reserved block count: 4856216
Free blocks: 68429391
Free inodes: 7157347
First block: 1
Block size: 1024
Fragment size: 1024
Reserved GDT blocks: 256
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 1024
Inode blocks per group: 256
Flex block group size: 16
Filesystem created: Tue Aug 2 07:39:40 2011
Last mount time: Thu Jan 24 23:15:41 2013
Last write time: Thu Jan 24 23:15:41 2013
Mount count: 10
Maximum mount count: 39
Last checked: Tue Aug 2 07:39:40 2011
Check interval: 15552000 (6 months)
Next check after: Sun Jan 29 06:39:40 2012
Lifetime writes: 13 TB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 0ecbfe75-57e3-4d4e-b4a8-bf0114dc0997
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Journal size: 32M
Journal length: 32768
Journal sequence: 0x32367a0d
Journal start: 1537
Regards,
Bron.
--
Bron Gondwana
brong@...tmail.fm
--
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
Powered by blists - more mailing lists