On 8/27/17 3:47 PM, Linus Torvalds wrote:
Note to people: I just committed the patch to update MAX_LFS_FILESIZE.
I made it use the simpler (and clearer) calculation of
((loff_t)ULONG_MAX << PAGE_SHIFT)
for the 32-bit case, and I did *not* change any other users.
Not a problem... I got ca
On 08/27/2017 02:47 PM, Linus Torvalds wrote:
> On Wed, Aug 23, 2017 at 2:01 PM, Andreas Dilger wrote:
>>
>> Doug,
>> I noticed while checking for other implications of changing MAX_LFS_FILESIZE
>> that fs/jfs/super.c is also working around this limit.
>
> Note to people: I just committed the pat
On Wed, Aug 23, 2017 at 2:01 PM, Andreas Dilger wrote:
>
> Doug,
> I noticed while checking for other implications of changing MAX_LFS_FILESIZE
> that fs/jfs/super.c is also working around this limit.
Note to people: I just committed the patch to update MAX_LFS_FILESIZE.
I made it use the simple
On 08/24/2017 05:20 AM, Doug Nazar wrote:
> On 8/23/17 5:01 PM, Andreas Dilger wrote:
>> Doug,
>> I noticed while checking for other implications of changing
>> MAX_LFS_FILESIZE
>> that fs/jfs/super.c is also working around this limit. If you are going
>> to submit a patch for this, it also makes
On 8/23/17 5:01 PM, Andreas Dilger wrote:
Doug,
I noticed while checking for other implications of changing MAX_LFS_FILESIZE
that fs/jfs/super.c is also working around this limit. If you are going
to submit a patch for this, it also makes sense to fix jfs_fill_super() to
use MAX_LFS_FILESIZE ins
On 8/23/17 4:13 PM, Linus Torvalds wrote:
Oh, right you are - I'm much too used to 64-bit, where
MAX_LFS_FILESIZE is basically infinite, and was jusr assuming that it
was something like the UFS bug we had not that long ago that was due
to the 32-bit limit.
But yes, on 32-bit, we are limited by
On Aug 23, 2017, at 2:13 PM, Linus Torvalds
wrote:
>
> On Wed, Aug 23, 2017 at 12:53 PM, Doug Nazar wrote:
>>
>> It's compiling now, but I think it's already set to MAX_LFS_FILESIZE.
>>
>> [ 169.095127] ppos=80180006000, s_maxbytes=7ff, magic=0x62646576,
>> type=bdev
>
> Oh, right y
On Wed, Aug 23, 2017 at 12:53 PM, Doug Nazar wrote:
>
> It's compiling now, but I think it's already set to MAX_LFS_FILESIZE.
>
> [ 169.095127] ppos=80180006000, s_maxbytes=7ff, magic=0x62646576,
> type=bdev
Oh, right you are - I'm much too used to 64-bit, where
MAX_LFS_FILESIZE is basic
The following commits cause short reads of block devices, however writes
are still allowed.
c2a9737f45e2 ("vfs,mm: fix a dead loop in truncate_inode_pages_range()")
d05c5f7ba164 ("vfs,mm: fix return value of read() at s_maxbytes")
When e2fsck sees this, it thinks it's a bad sector and tries to
On 8/23/17 3:37 PM, Linus Torvalds wrote:
On Wed, Aug 23, 2017 at 12:15 PM, Doug Nazar wrote:
The following commits cause short reads of block devices, however writes are
still allowed.
c2a9737f45e2 ("vfs,mm: fix a dead loop in truncate_inode_pages_range()")
d05c5f7ba164 ("vfs,mm: fix return v
On Wed, Aug 23, 2017 at 12:15 PM, Doug Nazar wrote:
> The following commits cause short reads of block devices, however writes are
> still allowed.
>
> c2a9737f45e2 ("vfs,mm: fix a dead loop in truncate_inode_pages_range()")
> d05c5f7ba164 ("vfs,mm: fix return value of read() at s_maxbytes")
>
> W
11 matches
Mail list logo