Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+xfs\:\s+fix\s+s_max_bytes\s+to\s+MAX_LFS

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+xfs\:\s+fix\s+s_max_bytes\s+to\s+MAX_LFS_FILESIZE\s+if\s+needed\s*$/: 9 ]

Total 9 documents matching your query.

1. [PATCH] xfs: fix s_max_bytes to MAX_LFS_FILESIZE if needed (score: 1): Author: Jeff Liu <jeff.liu@xxxxxxxxxx>; Date: Fri, 12 Apr 2013 18:26:40 +0800; On 32-bit machine, the s_maxbytes is larger than the MAX_LFS_FILESIZE limits if CONFIG_LBDAF is not enabled. Hence it's possible to create a huge file via buffered-IO write with a given offset beyond; /archives/xfs/2013-04/msg00273.html (9,756 bytes)
2. Re: [PATCH] xfs: fix s_max_bytes to MAX_LFS_FILESIZE if needed (score: 1): Author: "Michael L. Semon" <mlsemon35@xxxxxxxxx>; Date: Fri, 12 Apr 2013 11:20:30 -0400; I'll try this patch tonight. Thanks! BTW, after failures with CONFIG_LBDAF=n in previous xfstests, my kernels should have CONFIG_LBDAF=y, but I could be wrong. I'll check this when I get back to my t; /archives/xfs/2013-04/msg00289.html (10,017 bytes)
3. Re: [PATCH] xfs: fix s_max_bytes to MAX_LFS_FILESIZE if needed (score: 1): Author: "Michael L. Semon" <mlsemon35@xxxxxxxxx>; Date: Sat, 13 Apr 2013 01:03:54 -0400; I'll have to test this yet more, but preliminary results on a patched 3.9-rc6-git-sgi-dave-crc kernel look good: These were done on a 32-bit Pentium 4, BTW: generic/308, in order of testing... [F/F]; /archives/xfs/2013-04/msg00300.html (17,148 bytes)
4. Re: [PATCH] xfs: fix s_max_bytes to MAX_LFS_FILESIZE if needed (score: 1): Author: "Michael L. Semon" <mlsemon35@xxxxxxxxx>; Date: Sat, 13 Apr 2013 17:20:52 -0400; Update: My tests on my original hardware go exactly as they did in my Pentium 4 test. xfstests shared/[0-9][0-9][0-9] and xfs/003 through xfs/136 were run against it. No problems. Good job. I'm keepi; /archives/xfs/2013-04/msg00306.html (13,541 bytes)
5. Re: [PATCH] xfs: fix s_max_bytes to MAX_LFS_FILESIZE if needed (score: 1): Author: Jeff Liu <jeff.liu@xxxxxxxxxx>; Date: Tue, 16 Apr 2013 13:40:33 +0800; Hi Michael, Thanks a lot for help verifying this fix and sorry for my too late response since I have traveled to US two days ago. Ooops! it's wrong. My answer is misleading, you can think that I drin; /archives/xfs/2013-04/msg00348.html (16,060 bytes)
6. Re: [PATCH] xfs: fix s_max_bytes to MAX_LFS_FILESIZE if needed (score: 1): Author: "Michael L. Semon" <mlsemon35@xxxxxxxxx>; Date: Tue, 16 Apr 2013 01:55:44 -0400; You're welcome. Thanks for the explanation. Now everything makes logical sense. I'll re-run the tests with different block sizes. The tests have been run already with a) default mkfs options and b) w; /archives/xfs/2013-04/msg00349.html (13,428 bytes)
7. Re: [PATCH] xfs: fix s_max_bytes to MAX_LFS_FILESIZE if needed (score: 1): Author: Jeff Liu <jeff.liu@xxxxxxxxxx>; Date: Wed, 10 Jul 2013 14:28:20 +0800; Could anyone help to review this patch?; /archives/xfs/2013-07/msg00154.html (11,401 bytes)
8. Re: [PATCH] xfs: fix s_max_bytes to MAX_LFS_FILESIZE if needed (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Wed, 10 Jul 2013 16:48:55 +1000; Sorry, I missed it. Isn't MAX_LFS_FILESIZE defined on 32 bit systems to 8TB and the problem here is that we are overflowing at 16TB? If so, that means addin gthis patch will potentially cause problem; /archives/xfs/2013-07/msg00155.html (10,769 bytes)
9. Re: [PATCH] xfs: fix s_max_bytes to MAX_LFS_FILESIZE if needed (score: 1): Author: Jeff Liu <jeff.liu@xxxxxxxxxx>; Date: Wed, 10 Jul 2013 21:14:14 +0800; Hi Dave, Thanks for the quick response. Yes, but maybe I should say end_index is wrapped to zero rather than overflow in this situation. It seems that this change does not works to me because page->i; /archives/xfs/2013-07/msg00160.html (11,980 bytes)

Current List: 1 - 9
Page: [1]