RE: [PATCH 1/3] Fix problems on multi-TB filesystem and file

["Takashi Sato" <sho@tnes.nec.co.jp>]

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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/