<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12"> <TITLE>RE: free blocks count vs df() stat()</TITLE> </HEAD> <BODY>  Hi everyone, In follow-up, I found an explanation of the superblock and free blocks at <A HREF="http://www.angelfire.com/myband/binusoman/Unix.html#blocks">http://www.angelfire.com/myband/binusoman/Unix.html#blocks</A> which suggests free blocks represents a segment of available storage and the last value of the segment points to another segment of free blocks, so it is reasonable for it to be smaller than the block values shown by df() and stat(). But the interaction of lvm, ext3 and maxsize set at creation time and the consequence of going beyond that is still uncertain. -- Van Ly -----Original Message----- From: Van Ly Sent: Sat 6/27/2009 11:13 AM To: ext3-users@redhat.com Subject: free blocks count vs df() stat() Hi, Before going ahead with a fsck() and applying the patches on a RedHat 5.x system that has important data, I checked the numbers on the file system and depending on which way to look at it, the number for free/available space left could be 116Gb (see #1,3) or 24Gb (see #2). Does anyone know which to believe, 116Gb or 24Gb is free? I have diagnostic details appended below. Also, if the volume was created with logvol() (see #4) with the maxsize parameter used, does that affect later growth of the file system beyond maxsize (see #3)? My superficial understanding of inodes and blocks does not extend to lvm() and how that affects creation-time parameters shown by tune2fs. Thanks in advance, Van Ly -- # 1 # this comes close to 116Gb free <- `Available: 30246714` # stat -f /common File: "/common" ID: 0 Namelen: 255 Type: ext2/ext3 Block size: 4096 Fundamental block size: 4096 Blocks: Total: 60944400 Free: 33391866 Available: 30246714 Inodes: Total: 62914560 Free: 62037005 # 2 # free blocks suggests there is 24Gb free tune2fs 1.39 (29-May-2006) Filesystem volume name: <none> Last mounted on: <not available> Filesystem UUID: b78a127a-80d9-43e2-8f9c-143a82137eb8 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_re\ covery sparse_super large_file Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 62914560 Block count: 62914560 Reserved block count: 3145152 Free blocks: 6417762 Free inodes: 15443849 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 1009 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 32768 Inode blocks per group: 1024 Filesystem created: Thu Dec 18 12:06:47 2008 Last mount time: Sun Feb 1 07:25:25 2009 Last write time: Sun Feb 1 07:25:25 2009 Mount count: 3 Maximum mount count: -1 Last checked: Thu Dec 18 12:06:47 2008 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 First orphan inode: 30212898 Default directory hash: tea Directory Hash Seed: 15dea504-b626-476b-8513-fdc11b43abaf Journal backup: inode blocks # 3 # volume has since been grown to 233Gb # df -h /common Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg0-commonlv 233G 105G 116G 48% /common # 4 # redhat kickstart created volume logvol /common --fstype ext3 --name=commonlv --vgname=vg0 --size=512 --grow --maxsize=61440 </BODY> </HTML>