Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp2178774pxb; Fri, 25 Mar 2022 12:30:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwkxzsaZjOSiEuVJhnDrmcsY68aBxtEtGlLpC/23zblnSMicMLx70oso45oRU3fh5tXG33T X-Received: by 2002:a63:5502:0:b0:382:a7c2:66d3 with SMTP id j2-20020a635502000000b00382a7c266d3mr882243pgb.560.1648236604123; Fri, 25 Mar 2022 12:30:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648236604; cv=none; d=google.com; s=arc-20160816; b=b0n/lA4novXOggQTbmHoocGFrdPHDy4pvEPQcV4XsEADOwWsNBvGzAamEBEjRWDR5/ zmz0EV98PXsVfw5bL7ZK38biG9PHtd9uh9SWR1b9W93UygQUPvQqGr3mGxBY/XZ8QsTx Dy4norx99lV7++rB6GEOLpK6/9rbS4Ar7qsTDPjOAfFZppKfkhP5FEV1wtfffpIHgd4c RmFD1S8gzcuRAg9Htd2PXC1iP8U0WTEsR/2lUydoaRNtbd/XgGJvwtgROfpS0CX52VPm yMSmyMuah8Ow9qTYWtTUAvsS8ZaKTDTsIy78NHSmD0Bpp2C22bleUEJiFd46/y9U5DZa MQmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:subject:message-id:date:from:mime-version :dkim-signature; bh=c41pCClCkN5PFuk+yVxjeXx2WWOwThCPdPC/YOqI5Oc=; b=Pf0PGRTSiXvLR2Vtu3WA8+RM/53LI7h4ZusndVjAKHrXRPGTkiZkqqi2D3xwaFsX3T XeJnb8P2juTZmRptcTq/RSA5G2qFnWKo6vUhvM0MQBNTCHas7vBIBddJenWEIgoLQiXZ 8RYnBLx/cEk1yN5KlpONZIV7DyrMlDZ+r3KAi4YTu4OB7dA0QXYlft7tFsMY5OUt6L48 6YBlWJ70sqmyRVkVlvTvN8tdAnH087PSkHZxQ89c0ytstxqHoqQUA7itkwvki0PJMZ16 VCD4L5MieE3go56RznZ2KWkQOtcogIf642HnR/PYHeSfh+FZdDagC/alFSjZT3Vx55Gn BW1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=FKHElwsS; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id f30-20020a631f1e000000b003816043f0e1si3184302pgf.726.2022.03.25.12.30.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Mar 2022 12:30:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=FKHElwsS; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 19FFA190B78; Fri, 25 Mar 2022 11:42:35 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358483AbiCYGoO (ORCPT + 99 others); Fri, 25 Mar 2022 02:44:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45882 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347663AbiCYGoO (ORCPT ); Fri, 25 Mar 2022 02:44:14 -0400 Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 58CB6C6ED0; Thu, 24 Mar 2022 23:42:41 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id c11so5689699pgu.11; Thu, 24 Mar 2022 23:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=c41pCClCkN5PFuk+yVxjeXx2WWOwThCPdPC/YOqI5Oc=; b=FKHElwsSShqv1oat3UyiSLvlerb5qeYV4ERQ2SvkMp/1V3ZR3vKzzZH8C9IPiS0p24 4wtOlQPUE/4yepppcqaxxeK8uU0Diwceiw7CyOtFLclTHEj3jU3cD5Nq8Jbi166gMMh8 IoJPUpzASBVj6+bNdutkjscnWW6DivrFw4h6xeR6M5Py58sRjlk8ntzrwRQ6/onOHyNS xWuJ07r9TGK1VOydTfcFt7O12lE8OAo7X4zNF65o3R5oMEQp+b88FonNe9Egk3GUm+OP RXA5HEo2jZkSCHkU7wc34JQQN70oNrU5/HoxcCD7q/cj8qqEXlbCJPnOevHf1K4wph0p 4/YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=c41pCClCkN5PFuk+yVxjeXx2WWOwThCPdPC/YOqI5Oc=; b=SosZx99AHXhUvpppxReeAFtOPxFHPWBgquZfE4URd21HW85UXOyBeSgUoiT3Ygsb4I BZfaXw5bz5jxj9LBYEosZBxg+5vVS4uDtuW3xfnN5rvllJmiYDB7Nr2r9jU+/4EYj5Q4 wDD5j1/6WpoIy/sPZ7ry4YXw7s5Eg8e5x7SrT5yacRotsaOzBmwQXhP7flQE5z9Dw7b/ KNEsVbr0p2KTBrwnkNJ7DenCyWWmBsMz5WofB7JNDNqXn3KaeSf7AX1/z3dkjkV0hWHW bdbCYJbvLoyEHCiHfkYGXbQJaVbVy3WmN4QcmJGAySKajSTMbk4s9FhSr1o9FOL5yTMf vEMQ== X-Gm-Message-State: AOAM532RTO72nA2yo1ICtfAaYyDl8cGOz7RE9lGRRd5ni/KZ0jlppBUI V9l1st7Hf2TZOBdWgmw1dF9qI394pWE1v34HRM/A+J4Lcu9to8S0 X-Received: by 2002:aa7:86c6:0:b0:4fa:46d:6005 with SMTP id h6-20020aa786c6000000b004fa046d6005mr9010671pfo.86.1648190560379; Thu, 24 Mar 2022 23:42:40 -0700 (PDT) MIME-Version: 1.0 From: Fariya F Date: Fri, 25 Mar 2022 12:12:30 +0530 Message-ID: Subject: df returns incorrect size of partition due to huge overhead block count in ext4 partition To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org My eMMC partition is ext4 formatted and has about 100MB size. df -h command lists the size of the partition and the used percentage as below. Filesystem Size Used Avail Use% Mounted on /dev/mmcblk2p4 16Z 16Z 79M 100% /data For your reference, the returned values for statfs64( ) are statfs64("/data", 88, {f_type="EXT2_SUPER_MAGIC", f_bsize=1024, f_blocks=18446744073659310077, f_bfree=87628, f_bavail=80460, f_files=25688, f_ffree=25189, f_fsid={-1446355608, 1063639410}, f_namelen=255, f_frsize=1024, f_flags=4128}) = 0 The output dumpe2fs returns the following Block count: 102400 Reserved block count: 5120 Overhead blocks: 50343939 As per my kernel (4.9.31) code, the f_blocks is block_count - overhead blocks. Considering the subtraction with the above values results in a negative value this is interpreted as the huge value of 18446744073659310077. I have a script which monitors the used percentage of the partition using df -h command and when the used percentage is greater than 70%, it deletes files until the used percentage comes down. Considering df is reporting all the time 100% usage, all my files get deleted. My questions are: a) Where does overhead blocks get set? b) Why is this value huge for my partition and how to correct it considering fsck is also not correcting this Please note fsck on this partition doesn't report any issues at all. I am also able to create files in this partition.