All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Malone <ibmalone@gmail.com>
To: linux-ext4@vger.kernel.org
Subject: ext4 reserved blocks not enforced?
Date: Thu, 18 Jul 2019 16:26:19 +0100	[thread overview]
Message-ID: <CAL3-7Mp_0=tMReTRGB0u0OxynKXjLkCkr1X7d-+JwhwZpVfvvg@mail.gmail.com> (raw)

Hi,

We've got a number of ext4 fs on a LVM logical volume. When they get
'full' (0 available space according to df, normal user can't place any
more files), or ideally slightly before, we use lvm's lvextend command
with the -r option, which invokes fsadm, which I guess in turn uses
resize2fs.

Recently we extended a ~1.9TB filesystem by 20GB, however afterwards
df reported 0 available bytes. The LV had been increased and running
resize2fs reported that the fs was already the full size of the
device. tune2fs showed fewer free blocks than reserved blocks. Despite
this, normal users could create files on the filesystem (via nfs) and
copy several GB of data on without trouble. Forced fsck found no
issues, though with fragcheck enabled it reported plenty of blocks
that were not the expected length (and 9.4% non-contiguous).

Further, copying data on did not appear to change the reported free
nodes from tune2fs, though we didn't attempt to completely fill the
drive. We've since manually lowered the reserved blocks count below
the free blocks count in case the inverted situation was somehow
causing this behaviour.

Is this a bug? Normally once df reports 0 available normal users are
not able to add more data, regardless of remaining reserved space. If
it's expected behaviour can someone clarify what's happening?

This is the current tune2fs, reserved blocks was previously about
24924508, free blocks was already around 17315627 when we lowered the
reserved blocks:
tune2fs 1.42.9 (28-Dec-2013)
Filesystem volume name:   <none>
Last mounted on:          /mnt/research/ftd
Filesystem UUID:          0e4e6c45-a11b-43ff-84c8-ed21fbbde460
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index
filetype needs_recovery extent 64bit flex_bg sparse_super large_file
huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              126623744
Block count:              506472448
Reserved block count:     13107200
Free blocks:              17315627
Free inodes:              124820983
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      795
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    4096
Filesystem created:       Wed Jun 24 15:05:23 2015
Last mount time:          Thu Jul 18 13:23:59 2019
Last write time:          Thu Jul 18 13:23:59 2019
Mount count:              1
Maximum mount count:      -1
Last checked:             Thu Jul 18 13:21:25 2019
Check interval:           0 (<none>)
Lifetime writes:          12 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:      a5f445de-e71e-4601-9014-c82b8c8ec89e
Journal backup:           inode blocks


-- 
imalone
http://ibmalone.blogspot.co.uk

             reply	other threads:[~2019-07-18 15:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-18 15:26 Ian Malone [this message]
2019-07-19 18:04 ` ext4 reserved blocks not enforced? Theodore Y. Ts'o

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAL3-7Mp_0=tMReTRGB0u0OxynKXjLkCkr1X7d-+JwhwZpVfvvg@mail.gmail.com' \
    --to=ibmalone@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.