Hi,
I sent following patches three weeks ago, but I got only a few
responses.
So, I am sending them again. Comments are always welcome.
We made patches to fix problems that occur when handling a large
filesystem and a large file. It was discussed on the mails titled
"stat64 for over 2TB file returned invalid st_blocks".
They consist of three patches.
[1/3] Fix the problem that st_blocks is invalid when calling stat64
for > 2TB-file.
[2/3] Add blkcnt_t as the type of inode.i_blocks.
This enables you to make the size of blkcnt_t either 4 bytes
or 8 bytes on 32 bits architecture with new configuration
parameter (CONFIG_LSF).
[3/3] Fix the problem that kstatfs's entries related to blocks are
invalid on statfs64 for a network filesystem which has more
than 2^32-1 blocks when CONFIG_LBD is disabled. This fix was
proposed by Trond Myklebust.
The content of the patch attached to this mail is below.
- inode.i_blocks
Change the type from unsigned long to sector_t.
- kstat.blocks
Change the type from unsigned long to unsigned long long.
- stat64.st_blocks
Change the type from unsigned long to unsigned long long on
architectures (i386, m68k, sh).
Any feedback and comments are welcome.
Signed-off-by: Takashi Sato <[email protected]>
diff -uprN -X linux-2.6.15.org/Documentation/dontdiff linux-2.6.15.org/include/asm-i386/stat.h
linux-2.6.15-iblocks/include/asm-i386/stat.h
--- linux-2.6.15.org/include/asm-i386/stat.h 2006-01-03 12:21:10.000000000 +0900
+++ linux-2.6.15-iblocks/include/asm-i386/stat.h 2006-01-04 15:39:06.000000000 +0900
@@ -58,8 +58,7 @@ struct stat64 {
long long st_size;
unsigned long st_blksize;
- unsigned long st_blocks; /* Number 512-byte blocks allocated. */
- unsigned long __pad4; /* future possible st_blocks high bits */
+ unsigned long long st_blocks; /* Number 512-byte blocks allocated. */
unsigned long st_atime;
unsigned long st_atime_nsec;
diff -uprN -X linux-2.6.15.org/Documentation/dontdiff linux-2.6.15.org/include/asm-m68k/stat.h
linux-2.6.15-iblocks/include/asm-m68k/stat.h
--- linux-2.6.15.org/include/asm-m68k/stat.h 2006-01-03 12:21:10.000000000 +0900
+++ linux-2.6.15-iblocks/include/asm-m68k/stat.h 2006-01-04 15:39:06.000000000 +0900
@@ -60,8 +60,7 @@ struct stat64 {
long long st_size;
unsigned long st_blksize;
- unsigned long __pad4; /* future possible st_blocks high bits */
- unsigned long st_blocks; /* Number 512-byte blocks allocated. */
+ unsigned long long st_blocks; /* Number 512-byte blocks allocated. */
unsigned long st_atime;
unsigned long st_atime_nsec;
diff -uprN -X linux-2.6.15.org/Documentation/dontdiff linux-2.6.15.org/include/asm-sh/stat.h
linux-2.6.15-iblocks/include/asm-sh/stat.h
--- linux-2.6.15.org/include/asm-sh/stat.h 2006-01-03 12:21:10.000000000 +0900
+++ linux-2.6.15-iblocks/include/asm-sh/stat.h 2006-01-04 15:39:06.000000000 +0900
@@ -60,13 +60,7 @@ struct stat64 {
long long st_size;
unsigned long st_blksize;
-#if defined(__BIG_ENDIAN__)
- unsigned long __pad4; /* Future possible st_blocks hi bits */
- unsigned long st_blocks; /* Number 512-byte blocks allocated. */
-#else /* Must be little */
- unsigned long st_blocks; /* Number 512-byte blocks allocated. */
- unsigned long __pad4; /* Future possible st_blocks hi bits */
-#endif
+ unsigned long long st_blocks; /* Number 512-byte blocks allocated. */
unsigned long st_atime;
unsigned long st_atime_nsec;
diff -uprN -X linux-2.6.15.org/Documentation/dontdiff linux-2.6.15.org/include/linux/fs.h linux-2.6.15-iblocks/include/linux/fs.h
--- linux-2.6.15.org/include/linux/fs.h 2006-01-03 12:21:10.000000000 +0900
+++ linux-2.6.15-iblocks/include/linux/fs.h 2006-01-04 15:39:06.000000000 +0900
@@ -450,7 +450,7 @@ struct inode {
unsigned int i_blkbits;
unsigned long i_blksize;
unsigned long i_version;
- unsigned long i_blocks;
+ sector_t i_blocks;
unsigned short i_bytes;
spinlock_t i_lock; /* i_blocks, i_bytes, maybe i_size */
struct semaphore i_sem;
diff -uprN -X linux-2.6.15.org/Documentation/dontdiff linux-2.6.15.org/include/linux/stat.h
linux-2.6.15-iblocks/include/linux/stat.h
--- linux-2.6.15.org/include/linux/stat.h 2006-01-03 12:21:10.000000000 +0900
+++ linux-2.6.15-iblocks/include/linux/stat.h 2006-01-04 15:39:06.000000000 +0900
@@ -69,7 +69,7 @@ struct kstat {
struct timespec mtime;
struct timespec ctime;
unsigned long blksize;
- unsigned long blocks;
+ unsigned long long blocks;
};
#endif
-- Takashi Sato
"Takashi Sato" <[email protected]> wrote:
>
> Hi,
>
> I sent following patches three weeks ago, but I got only a few
> responses.
> So, I am sending them again. Comments are always welcome.
Please don't send multiple patches under the same Subject:. Please try to
choose nice names for each email, as per
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt, thanks.
> We made patches to fix problems that occur when handling a large
> filesystem and a large file. It was discussed on the mails titled
> "stat64 for over 2TB file returned invalid st_blocks".
It's best to not refer to an email thread in this manner - the covering
description for a patch should be a self-contained standalone thing which
contains all necessary info to understand the patch.
Could you remind us what problems this patch series solves? It _appears_
to solve statfs reporting. Does it fix anything else? There have been a
couple of reports of filesystems outright failing on >2TB devices - does it
address those problems, if so how?
> The content of the patch attached to this mail is below.
> - inode.i_blocks
> Change the type from unsigned long to sector_t.
> - kstat.blocks
> Change the type from unsigned long to unsigned long long.
> - stat64.st_blocks
> Change the type from unsigned long to unsigned long long on
> architectures (i386, m68k, sh).
Seems reasonable.
Hi,
> > I sent following patches three weeks ago, but I got only a few
> > responses. So, I am sending them again. Comments are always
> > welcome.
>
> Please don't send multiple patches under the same Subject:. Please
> try to choose nice names for each email, as per
> http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt, thanks.
I see, I'll care about it.
> > We made patches to fix problems that occur when handling a large
> > filesystem and a large file. It was discussed on the mails titled
> > "stat64 for over 2TB file returned invalid st_blocks".
>
> It's best to not refer to an email thread in this manner - the
> covering description for a patch should be a self-contained standalone
> thing which contains all necessary info to understand the patch.
I'll care about it too.
> Could you remind us what problems this patch series solves? It
> _appears_ to solve statfs reporting. Does it fix anything else?
> There have been a couple of reports of filesystems outright failing on
> >2TB devices - does it address those problems, if so how?
This patch series fixes the following problems on 32 bits architecture.
o stat64 returns the lower 32 bits of blocks, although userland
st_blocks has 64 bits, because i_blocks has only 32 bits.
The ioctl with FIOQSIZE has the same problem.
o As Dave Kleikamp said, making >2TB file on JFS results in writing
an invalid block number to disk inode. The cause is the same as
above too.
o In generic quota code dquot_transfer(), the file usage is calculated
from i_blocks via inode_get_bytes(). If the file is over 2TB,
the change of usage is less than expected. The cause is the
same as above too.
o As Trond Myklebust said, statfs64's entries related to blocks are
invalid on statfs64 for a network filesystem which has more than
2^32-1 blocks with CONFIG_LBD disabled. [PATCH 3/3]
-- Takashi Sato