<---- template headericclude ----->
What eats my disk space?
FedoraForum.org - Fedora Support Forums and Community
Results 1 to 12 of 12
  1. #1
    Join Date
    Sep 2010
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    What eats my disk space?

    I'm trying to understand what's eating my disk space while I partition and format it. So I have a 2TB HD and make one partition with fdisk.
    fdisk /dev/sda
    Command (m for help): p

    Disk /dev/sda: 2000.4 GB, 2000398934016 bytes
    255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0x671ef452

    Device Boot Start End Blocks Id System
    /dev/sda1 63 3907024064 1953512001 83 Linux

    Command (m for help): v
    Remaining 5165 unallocated 512-byte sectors

    So I have a total number of bytes (Total=2000398934016 bytes, because of the 1000/1024 issue) and I loose approx 2.5MB (Unalloc=2644480 bytes). Not sure why this happens, but hej, it's just 2.5MB. Now I create a filesystem like this:
    mkfs.ext4 -L /data10 -m 0 /dev/sda1

    Not sure whether it is safe to set the super-user reserved blocks to zero (this is just a datadisk). Anyway, lets see what we have left:
    df --block-size=1
    Filesystem 1B-blocks Used Available Use% Mounted on
    /dev/sda1 1969006952448 204828672 1968802123776 1% /data10

    So I have a total of (Left=1969006952448 bytes) from which (Used=204828672 bytes) are taken. So we see three stages of disk space loss:
    1. Unallocated space by fdisk (Unalloc): ~2.5MB
    2. Space taken up by ??? (Total-Unalloc-Left): ~29.2GB
    3. Space already in use by ??? (Used): ~195.3MB

    So it turns out I loose ~29.4GB in total and I have ~1.79TB left. Taking into account that I have 20 disks, I loose ~0.5 TB.

    So finally my question: is this normal? Could anyone tell me what these three losses are all about (newbie here)? Can I do something about them? I was just checking some NTFS disks and the space lost is so small I couldn't even see it.

  2. #2
    Join Date
    May 2005
    Location
    Sonoran Desert
    Posts
    2,420
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: What eats my disk space?

    This is the best summary a quick google search could give me: http://rwmj.wordpress.com/2009/11/08...data-overhead/

    The difference between ext4 at 3.2% metadata overhead and NTFS at 0.5% is comparatively large, but disk space is cheap.

  3. #3
    Join Date
    Aug 2009
    Location
    Waldorf, Maryland
    Posts
    7,343
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: What eats my disk space?

    Quote Originally Posted by WoxDN
    I'm trying to understand what's eating my disk space while I partition and format it. So I have a 2TB HD and make one partition with fdisk.
    fdisk /dev/sda
    Command (m for help): p

    Disk /dev/sda: 2000.4 GB, 2000398934016 bytes
    255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0x671ef452

    Device Boot Start End Blocks Id System
    /dev/sda1 63 3907024064 1953512001 83 Linux

    Command (m for help): v
    Remaining 5165 unallocated 512-byte sectors

    So I have a total number of bytes (Total=2000398934016 bytes, because of the 1000/1024 issue) and I loose approx 2.5MB (Unalloc=2644480 bytes). Not sure why this happens, but hej, it's just 2.5MB.
    No - you have everything - 3907029168 * 512 = 2000398934016 bytes,
    which when rounded off is 2000.4 GB.

    Now I create a filesystem like this:
    mkfs.ext4 -L /data10 -m 0 /dev/sda1

    Not sure whether it is safe to set the super-user reserved blocks to zero (this is just a datadisk). Anyway, lets see what we have left:
    df --block-size=1
    Filesystem 1B-blocks Used Available Use% Mounted on
    /dev/sda1 1969006952448 204828672 1968802123776 1% /data10

    So I have a total of (Left=1969006952448 bytes) from which (Used=204828672 bytes) are taken. So we see three stages of disk space loss:
    1. Unallocated space by fdisk (Unalloc): ~2.5MB
    Which appears false
    2. Space taken up by ??? (Total-Unalloc-Left): ~29.2GB
    3. Space already in use by ??? (Used): ~195.3MB

    So it turns out I loose ~29.4GB in total and I have ~1.79TB left. Taking into account that I have 20 disks, I loose ~0.5 TB.

    So finally my question: is this normal? Could anyone tell me what these three losses are all about (newbie here)? Can I do something about them? I was just checking some NTFS disks and the space lost is so small I couldn't even see it.
    Yes, it is normal. You are forgetting the storage required for inode list,
    and the storage for the journal, oh yes, don't forget the bitmap allocation
    storage is block clusters.... You might check the manpage on mkfs.ext4 for options that allow you to change some things around.

    For instance, the defaults for ext4 are:
    blocksize=4096,
    inode_size=256,
    inode_ratio = 16384

    The inode ratio is the number of blocks per inode allocated, so

    2000398934016/16384 = 122094661.5 inodes, ot 233094662 inodes.

    This translates into 233094662 * 256 = 31256233472 bytes, or
    31256.233472 -> 3GB.

    The journal, on the other hand, could be as large as 102,400 filesystem
    blocks (4096 bytes), or an additional 400 MB (roughly).

    The bitmap allocation table size(s) are determined based on the number
    of blocks on the disk. If there is one block/bit, then (using 4096 byte blocks) means there must be 488378646 bits in the allocation tables..
    which is 61047331 bytes, or an additional 61 MB.

    BTW, there are also superblock backups stored on the disk as well,
    and these also take up space

    On top of all this is the 10% reserved for root - and yes, for data disks
    this could be trimmed, especially for such a large disk that root will
    not be using for storage (well, unless you decide to keep backups there).

    I can't find all the defaults, that would take more googleing all
    the defaults.

  4. #4
    stevea Guest

    Re: What eats my disk space?

    Quote Originally Posted by jpollard
    No - you have everything - 3907029168 * 512 = 2000398934016 bytes,
    which when rounded off is 2000.4 GB.

    ...
    Which appears false
    Wrong. He lost ~2.5MB from the filesytstem partition.

    He chose to create a partition table on the device and this, causes the file system to start at logical block 63. The first ~31.5KiB (blocks 0...62) are user for partition table and initial bootloader and are lost to the filesystem space. In this example case (one big filesys per device) the OP could have done a "mkfs ... /dev/sda" and not created a partition table.

    The majority of the loss is at the END of the disk. The FS stops at 3907024064 but the device has sectors out to 3907029168, so he lost 5104 512B sectors (2,613,248B) at the end of disk. This loss is due to the default behaviour of most of the disk partition programs which cause them to round to a "cylinder boundary", but the disk geometry is mostly baloney in recent decades (that drive doesn't have 255 heads for example).

    So the partitioning program believes the fake drive geometry and calculates a "fake cylinder" is 255(heads) * 63 sectors = 16065 sectors. The end of partition is at sector 3907024064 (sectors are numbered from zero) which is exactly 243201 cylinders.
    243201 * 16065 = 3907024065 (which is sector number 0, 1, 2, ... 3907024064).

    Bottom line -

    1/ If you want to recoup the 2.6MB at the end if disk, then use gparted and select "align: None" when you create the partition. This is actually a good idea, tho' as the OP says - it's only 2.6MB.

    2/ You can recoup the 31+KB a the head of disk by removing the partition table (means the disk is one big partition). I'd have to label that idea "Not Smart". The 32KB header area means the partition type is identifiable and can hold the initial bootloader. That's cheap goods for 31.5KiB of disk.

    =====

    The main question ha been answered. The loss is due to ext4 metadata.
    You can examine the actual usage with the
    dumpe2fs -h /dev/sda1
    command. You are losing about (29.4GB/2000GB) ~1.5% to ext4 metadata overhead.

    Nearly ALL of that loss of that loss (1.5%) is used for the default inode allocation.
    JP had the right approach, but he slipped a digit (He should have gotten 30GB). More usefully there is a 256B inode allocated for every 16KiB of allocatable data block, so
    256 / 16384 = 0.015625 - so 1.5625% of the data blocks are used as pre-allocated inodes.

    Actually this figure is a *little* high. The ext4 mkfs allocates some reserved blocks for bitmap, GDP and journal and a few other tiny things - then calculates one inode per 16KiB of data excluding the inode amount. So it comes to (0.015625/1.0156325) or 1.538% of the remaining (non-Journal, non-bitmap, ...) blocks.

    So your missing 29.xGB is essentially all used for inodes (well maybe 0.25GB of journal). This default number of inodes is calculated for an average file size as small as 16KB. If you know you will be using this for very large fails then you can decrease the inode allocation. OTOH if you need lots of tiny files you will need more inodes(very unlikely). The current inode allocation seems 3x or 4x overkill for my use and I create lots of little source and binary files (building kernels and tools).
    --

    IMO setting "-m 0" as the OP does is a questionable idea, and could harm performance significantly since these are user to avoid fragmentation (unclear how), but setting it to "-m 1" is plenty for say a 150+GB partition. They need more resolution on that item, and it's value should be dynamically determined. I think a couple GB for the super-user mess should be plenty, but that's 0.1% for you.

    Perhaps the smart way to handle he super-user resevred blocks is to tset it to zero "-m 0" as OP has done. Then use the command
    tune2fs -r 262144 /dev/sda1
    which sets the reserved block count (4KiB blocks) to 1GiB. Maybe 2GB would be better, but you certainly don't need to use 20GB(1% of disk), and 5% is crazy.
    Last edited by stevea; 25th September 2010 at 10:05 PM.

  5. #5
    Join Date
    Aug 2009
    Location
    Waldorf, Maryland
    Posts
    7,343
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: What eats my disk space?

    drat... missed by that much...

  6. #6
    stevea Guest

    Re: What eats my disk space?

    OK - I've read a little further on the SU(super-user)-reserved-blocks topic and it seems that since ~2003/2004 ext3 has used a block reservation scheme to reduce fragmentation. This is a kernel feature and didn't require any ext3 filesystem changes. Ext4 has it's own active defragmenter

    The SU-reserved blocks are just allocated out of the normal pool of blocks. It works something ike this - when the pool of available blocks gets low - (at or below the reserved block reservation) then the kernel refuses to allocate blocks for any process that is not superuser. This means all your user apps get an error from the syscalls, but syslogd and the kernel services keep running a while longer.

    The main reason why the they claim this improves fragmentation, is that on the older filesystems (ext2, ext3 before the reservation scheme) the allocation could become fairly fragmented, but since 5% of the blocks were reserved they just kept allocating the larger chunks and leaving the "fragments" for the SU-reservation.

    So *IF* you ever used up the non-reserve space on disk, then only ssyslogd and SU processes can allocate more block, but the blocks left are likley to be very fragmented and the emergency "disk-out-of-space" syslogd logs (for example) would get bad I/O performance and be very fraggy.

    On later ext3 and also for ext4, this same effect may help performance a little when your disk is really full (like 99+%), but it seems rather pointless unless you really believe root should be given the last few % of space when the disk fills.

    ===

    My advise after reading this is that for ext4, set the reservation to ZERO (the OP's "mkfs -m 0 ..." option) and only create a super-user-reservation for the file system holding /var - and only *IF* the system is so badly managed that it would ever run out of available space before being administered.

    Many home/soho users (who can mismanage and not pay attention to filled disks) might want to set the root file system ext4 su-reservation to a few hundred MB - but that's a lot of logs. You could easily see what went wrong a 50MB syslogd reservation for SU.
    --

    The other important saving is in estimating your average file size and reducing the number of inodes allocation. For this you can use the mkfs.ext4 options "-i" or "-I".

    FWIW my average file size is running 14.5 4KiB blocks (58KiB). This is calculated by taking the allocate block divided by the number of inodes in use.

    So I could bump my blocks-per-inode from the default of 4 up to 8(16Kib to 32KiB) cut the number of inodes in half and still have a good margin of safety. I'd gain about 0.75% of the partition size for this effort.

    ==

    i learned something useful today - thanks for the question.
    Last edited by stevea; 25th September 2010 at 11:11 PM.

  7. #7
    Join Date
    Aug 2009
    Location
    Waldorf, Maryland
    Posts
    7,343
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: What eats my disk space?

    I would add some other filesystems/directories to just /var - /tmp /usr/tmp (which
    in current systems are sym links to /var/tmp)

    Also /etc, /usr (mostly for system updates - you don't want an update failure
    due to disk space to crap all over your system).

    In some cases /usr/local is in the same boat - historically this has been treated
    as the site local "root" file system, and as such, it sometimes also has logs.

    As for using the average size... That depends.

    The "average" size can be skewed by a few very large files. What you really want
    to use is the median, which can be much lower than the average, but it does
    require more analysis than a simple average - which can work fairly well.

    As a side note - the /etc/mke2fs.conf contains alternate options that can be specified
    by name - The defaults associated with the names have been used for various
    workloads and found useful. These names are used with the mkfs -T option and
    can/will alter the metadata allocations.

  8. #8
    Join Date
    Sep 2010
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: What eats my disk space?

    Thanks for your elaborate answers. What I understood was:
    1. Use gparted instead of fdisk for the alignment issue, but still partition the hard drive.
    2. Use the "-m 0", because these 2TB disks are just data disks (no /var, /etc, /usr etc.)
    3. Estimate the median file size and adapt the inodes.

    What about journal size? What is the optimal journal size?

    Another thing: since the biggest issue is the metadata overhead from ext4, shouldn't I be using another filesystem for my 2TB data disks?

  9. #9
    Join Date
    Jul 2010
    Posts
    270
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: What eats my disk space?

    Hello All,

    Great thread! Thanks to OP for starting the conversation. I've been reading this thread and did a little experimentation with my filesystems.

    Take away items (for easy use of the info here):

    1. Even if you are unable to "re-create" the fs, usable space may be recovered by running "tune2fs -m0 <DEVICE>".

    2. Even if you don't want to calculate file size averages, inode ratios, and the like, you can use "mkfs -m 0 -T largefile <DEVICE>" to create a file system appropriate to use with large files.

    Cheers,


    oxala

  10. #10
    Join Date
    Aug 2009
    Location
    Waldorf, Maryland
    Posts
    7,343
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: What eats my disk space?

    I wouldn't -

    The optimum size for a journal is the amount of updates being applied to the
    filesystem...If it is a very busy one, then you want more. The default size is usually
    sufficient.

    As for using a different filesystem - I wouldn't. The advantage ext4 has is the
    low fragmentation, (and automatic defragmentation) built in, plus the
    journal reduces the need to run filesystem diagnostics (and rebuild) after
    system failures.

    One problem with large filesystems is that it can take quite a while to back one up,
    hence the use of mirroring (though not perfect - a mistake made on one is a
    mistake made on both).

  11. #11
    Join Date
    Sep 2010
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: What eats my disk space?

    Quote Originally Posted by WoxDN
    What I understood was:
    1. Use gparted instead of fdisk for the alignment issue, but still partition the hard drive.
    Actually, just using "fdisk -u /dev/sda" and then add 1 partition that covers the whole disk, will allow allocation of everything except for the first 63 sectors (sector 0: MBR, sectors 1-62: lost but sometimes used by GRUB). Since this is just a data disk and GRUB has nothing to do with it, I lost 62x512 bytes but I think I can handle it Anyway, I just wanted to know what was going on there.

    I do have some additional questions about mke2fs and mke2fs.conf.
    1. If I would do "mke2fs /dev/sda1" then it would use the parameters listed under [defaults] in mke2fs.conf
    2. If I would do "mke2fs -T ext4 /dev/sda1" then it would use the parameters listed under [defaults] and under [fs_types]-->ext4 in mke2fs.conf

    If I understand it correctly, mke2fs makes a "second extended file system". Adding the feature "has_journal" makes it ext3, adding "has_journal, extent,..." makes it ext4. Since these extra features are under [fs_types]-->ext4, using "-T ext4" will cause the create of an ext4 file system. So what's "-t ext4" doing? An what if you use "mkfs.ext4"?

  12. #12
    Join Date
    Aug 2009
    Location
    Waldorf, Maryland
    Posts
    7,343
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: What eats my disk space?

    Extents allow for faster I/O - when allocating/extending a file it allocates in extents,
    which are multiple blocks. This improves performance by eliminating future expansion
    and reduces fragmentation because the extents would normally be contiguous.

    Extents also speed reading by making readahead operations faster with less head
    movement. This is beneficial to video and audio by reducing the causes for pausing
    for I/O.

    Normally you would only use "mkfs" and let/tell mkfs which filesystem to create.
    Mkfs will invoke whichever mkfs.xxx is necessary.

    As a point - mkfs.ext2, mkfs.ext3, and mkfs.ext4 are the same program (all the names
    refer to the same file inode - meaning they are hard links). The only difference is
    that the application can use the invoked name (mkfs.ext2/3/4) to determine which
    filesystem to create. All three filesystems are upwardly compatable - but once you
    have journal it CAN be changed from ext3 back to ext2. But once extents are USED
    an ext4 cannot be returned to ext3 (the extents will show up as a corrupted
    filesystem).

Similar Threads

  1. Yum "info" eats disk space?
    By Chilly Willy in forum Using Fedora
    Replies: 11
    Last Post: 24th November 2008, 05:38 PM
  2. Disk space
    By tovarish in forum Using Fedora
    Replies: 0
    Last Post: 12th September 2007, 05:32 PM
  3. Replies: 2
    Last Post: 30th August 2006, 02:20 PM
  4. out of disk space
    By krafty1 in forum Using Fedora
    Replies: 7
    Last Post: 10th June 2006, 09:18 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
[[template footer(Guest)]]