free blocks count vs df() stat()

[Van Ly]

Hi everyone,

In follow-up, I found an explanation of the superblock and free blocks at

http://www.angelfire.com/myband/binusoman/Unix.html#blocks

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 at 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 




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/ext3-users/attachments/20090629/5e02ab42/attachment.htm>