Very Computer

There's an optimization in ext2fs where if a block of a file contains
all zeros, then that block is not stored.  This is particularly relevant
in cases where files are extended with lseek --- the intervening space
is intentionally filled with zeros.  Do you think that could be
contributing to the discrepancy?

- Josh

Hello all,

I  have been sweating * trying to get my block quotas to agree on my
ext2 partition recently - it seems that a file-system bug is partly
responsible. I managed to produce this directory entry by extending a
file using lseek() (according to the manual, this use of lseek is
allowed):

bash$ ls -als
total 27
   1 drwxr-xr-x   2 Chris    users        1024 Feb 15 23:09 .
   1 drwxr-xr-x   9 Chris    users        1024 Feb 13 01:04 ..
   1 -rw-r--r--   1 Chris    users          76 Jan 23 00:17 Hello.c
   2 -rw-r--r--   1 Chris    users        1103 Feb 15 16:19 Makefile
   1 -rw-------   1 Chris    users        8016 Feb 15 22:40 TESTME
   3 -rw-r--r--   1 Chris    users        2664 Nov 10 22:18 copy.c

The guilty party here is the file TESTME. I trust you will agree that an
8016-byte file should use more than one block on a 1024 byte-blocksize
filesystem (which I have)...

I have attached the program I used to generate this result.

Have fun with this one,
Cheers,
Chris.

[ testseek.c < 1K ]
#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>

const char *const szTestFile = "./TESTME";
#define FAILURE  -1

typedef struct tagChunk
        {
          int a1, a2, a3, a4;
        } CHUNK;

int main()
{
  int fd;

  fd = open(szTestFile,O_CREAT|O_TRUNC|O_RDWR,S_IRUSR|S_IWUSR);
  if (fd != FAILURE)
  {
    const CHUNK stChunk = {0,0,0,0};
    lseek(fd,500*sizeof(CHUNK),SEEK_SET);
    write(fd,&stChunk,sizeof(stChunk));
    close(fd);
  }

  return 0;

Quote:}

Quote:>This is a multi-part message in MIME format.
>--------------6FE5D189D8E3157482700AF4
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>Hello all,
>I  have been sweating * trying to get my block quotas to agree on my
>ext2 partition recently - it seems that a file-system bug is partly
>responsible. I managed to produce this directory entry by extending a
>file using lseek() (according to the manual, this use of lseek is
>allowed):
>bash$ ls -als
>total 27
>   1 drwxr-xr-x   2 Chris    users        1024 Feb 15 23:09 .
>   1 drwxr-xr-x   9 Chris    users        1024 Feb 13 01:04 ..
>   1 -rw-r--r--   1 Chris    users          76 Jan 23 00:17 Hello.c
>   2 -rw-r--r--   1 Chris    users        1103 Feb 15 16:19 Makefile
>   1 -rw-------   1 Chris    users        8016 Feb 15 22:40 TESTME
>   3 -rw-r--r--   1 Chris    users        2664 Nov 10 22:18 copy.c
>The guilty party here is the file TESTME. I trust you will agree that an
>8016-byte file should use more than one block on a 1024 byte-blocksize
>filesystem (which I have)...

[0] Ok, there are valid reasons why it should write the whole thing
to disk in some cases.  It is a tradeoff.

Quote:>The guilty party here is the file TESTME. I trust you will agree that an
>8016-byte file should use more than one block on a 1024 byte-blocksize
>filesystem (which I have)...

--Tim Smith

Quote:>There's an optimization in ext2fs where if a block of a file contains
>all zeros, then that block is not stored.  This is particularly relevant

--Tim Smith

I am trying to write my own version of quotacheck (for the sheer hell of it), and
am trying to do so in such a way that I don't depend on the internal structure of
/quota.user etc. To this end I do the following:

-create a blank quota file
-enable quotas
-search the filesystem, compiling a list of which user owns which file (yes, I am
aware of hard/soft links) and how many blocks that file owns. This is done using
lstat(), and I do adjust the "raw" block count to get the number of filesystem
blocks.
-use this info to set the quota using quotactl()
-disable quotas again, thus prompting the kernel to write its data to disc.

There are other considerations such as group quotas and various "what if ...?"
scenarios, but the approach outlined above is the one with the problem. The
problem appears thus:

-Disable quotas and delete any /quota.* files.
-Create a "null" quota file containing a zero entry for root. (I hope to move
away from this, but for now...)
-Enable quotas
-Scan the disc, but don't assign any quotas
-Disable quotas.

The program reports that root is using 18253 blocks for 3189 inodes.

-Repeat the above procedure, but this time DO assign quotas

Output from the quota system: root is using 18261 blocks for 3189 inodes.

- Repeat the procedure, NOT assigning quotas

Output from the filesystem search: root is using 18256 blocks for 3189 inodes.

bash$ ls -als /quota.*
   4 -rw-------   1 root     root        16032 Feb 16 22:25 /quota.user

Conclusion? root's block-quota is 5 blocks astray. I have no idea where these
missing blocks are. However, I do know that the kernel allocated them all while
writing out the quota-file. And the approach the kernel uses to write the
quota-file is to set the file-position to the correct offset and then call the
file's write-operation; i.e. the quota-file is truly a sparse file. I did occur
to me to wonder whether some of the "phantom" blocks are somehow being added into
the block-quota, though.

Any insights would be welcome,
Cheers.
Chris.