tune2fs -m "reserved space?"

Justin Conover justin.conover at gmail.com
Tue Oct 4 18:19:05 UTC 2005


On 10/4/05, Arjan van de Ven <arjanv at redhat.com> wrote:
>
> On Tue, 2005-10-04 at 12:24 -0500, Justin Conover wrote:
> > tune2fs
> > -m reserved-blocks-percentage
> > -r reserved-blocks-count
> >
> > If what I have read is correct, -m by default uses 5% of the disk
> > space for "reserved root use" On my server at home with a /home of
> > 1TB thats about 50GB of wasted space.
> >
> > Is this reserved space actually used by ANYTHING? Like LVM, some kind
> > of fragmentation?
>
> well for emergency root stuff; logging in without any disk space is
> hard; lots of stuff wants to make temporary files etc.
>
> but your second point it true too: most filesystems (ext3 but most
> others) start to fragment like hell if they go over about 95% full.
>
> Think of it this way: if you have half your disk empty, the filesystem
> can do a proper job of finding non-fragmented space.
> If only 0.0001% is free, it has almost no freedom of choice, resulting
> in "you get it in whatever order some things become free".
> Those are sort of extremes; there's been a bunch of research and the
> outcome was that 5% free seems to be sort of the turning point in this
> respect.
>
> I suspect that research predates the Tb sized volumes, so I don't know
> if it maybe is 1% on such volumes, but then again to some extend the
> freedom needed will scale with the FS size
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQBDQsEXpv2rCoFn+CIRAvUXAJ0SH+Pc9eXpinhuBGZ+DM4r5wTCtgCgi+7B
> hxT89EtumMwOF13z0l0KP9Q=
> =C5z1
> -----END PGP SIGNATURE-----


This is a vg on the 1TB a 625GB slice, If i'm reading this correctly than I
have about 32GB "free" space right?

vgdisplay "VolGroup01"
--- Volume group ---
VG Name VolGroup01
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 5
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 2
Max PV 0
Cur PV 1
Act PV 1
VG Size 931.53 GB
PE Size 32.00 MB
Total PE 29809
Alloc PE / Size 20000 / 625.00 GB
Free PE / Size 9809 / 306.53 GB
VG UUID Lrid7V-3i0U-35SD-zLCU-kDYB-xmGu-r15Y6E

df -k /dev/VolGroup01/LogVol00
Filesystem 1K-blocks Used Available Use% Mounted on
- 517924 184 517740 1% /dev


tune2fs -l /dev/VolGroup01/LogVol00
tune2fs 1.35 (28-Feb-2004)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 035dc33b-726e-40d0-8425-461f7b9b971b
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype
needs_recovery sparse_super large_file
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 65536000
Block count: 131072000
Reserved block count: 6553280
Free blocks: 33234208
Free inodes: 52339650
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1017
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Sat Aug 27 07:34:52 2005
Last mount time: Sat Aug 27 18:43:05 2005
Last write time: Sat Sep 17 11:20:43 2005
Mount count: 9
Maximum mount count: -1
Last checked: Sat Aug 27 07:34:52 2005
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 8b7d8357-7489-4d3b-92da-8c186ecca90a
Journal backup: inode blocks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20051004/04b1bd2d/attachment.htm>


More information about the fedora-test-list mailing list