Messages in this thread | | | From | "Takashi Sato" <> | Subject | RE: [PATCH 1/3] Fix problems on multi-TB filesystem and file | Date | Fri, 13 Jan 2006 22:48:52 +0900 |
| |
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/
| |