On Mon, 3 Feb 2014, Christoph Hellwig wrote:
> On Fri, Jan 31, 2014 at 03:20:17AM -0500, Mikulas Patocka wrote:
> > So if you think you can support 16TiB devices and leave pgoff_t 32-bit,
> > send a patch that does it.
> >
> > Until you make it, you should apply the patch that I sent, that pre
On Fri, Jan 31, 2014 at 03:20:17AM -0500, Mikulas Patocka wrote:
> So if you think you can support 16TiB devices and leave pgoff_t 32-bit,
> send a patch that does it.
>
> Until you make it, you should apply the patch that I sent, that prevents
> kernel lockups or data corruption when the user u
On Thu, 30 Jan 2014, James Bottomley wrote:
> > So, if you want 64-bit page offsets, you need to increase pgoff_t size,
> > and that will increase the limit for both files and block devices.
>
> No. The point is the page cache mapping of the device uses a
> manufactured inode saved in the bac
On Thu, 2014-01-30 at 21:43 -0500, Mikulas Patocka wrote:
>
> On Thu, 30 Jan 2014, James Bottomley wrote:
>
> > > A device may be accessed direcly (by opening /dev/sdX) and it creates a
> > > mapping too - thus, the size of a mapping limits the size of a block
> > > device.
> >
> > Right, that
On Thu, 30 Jan 2014, James Bottomley wrote:
> > A device may be accessed direcly (by opening /dev/sdX) and it creates a
> > mapping too - thus, the size of a mapping limits the size of a block
> > device.
>
> Right, that's what I suspected below. We can't damage large block
> support on file
On Thu, 2014-01-30 at 19:20 -0500, Mikulas Patocka wrote:
>
> On Thu, 30 Jan 2014, James Bottomley wrote:
>
> > On Thu, 2014-01-30 at 18:10 -0500, Mikulas Patocka wrote:
> > >
> > > On Thu, 30 Jan 2014, James Bottomley wrote:
> > >
> > > > Why is this? the whole reason for CONFIG_LBDAF is supp
On Thu, 30 Jan 2014, James Bottomley wrote:
> On Thu, 2014-01-30 at 18:10 -0500, Mikulas Patocka wrote:
> >
> > On Thu, 30 Jan 2014, James Bottomley wrote:
> >
> > > Why is this? the whole reason for CONFIG_LBDAF is supposed to be to
> > > allow 64 bit offsets for block devices on 32 bit. It
On Thu, 2014-01-30 at 18:10 -0500, Mikulas Patocka wrote:
>
> On Thu, 30 Jan 2014, James Bottomley wrote:
>
> > Why is this? the whole reason for CONFIG_LBDAF is supposed to be to
> > allow 64 bit offsets for block devices on 32 bit. It sounds like
> > there's somewhere not using sector_t ... o
On Thu, 30 Jan 2014, James Bottomley wrote:
> Why is this? the whole reason for CONFIG_LBDAF is supposed to be to
> allow 64 bit offsets for block devices on 32 bit. It sounds like
> there's somewhere not using sector_t ... or using it wrongly which needs
> fixing.
The page cache uses unsigne
On Thu, 2014-01-30 at 15:40 -0500, Mikulas Patocka wrote:
> When running the LVM2 testsuite on 32-bit kernel, there are unkillable
> processes stuck in the kernel consuming 100% CPU:
> blkid R running 0 2005 1409 0x0004
> ce009d00 0082 ffcf c11280ba 0060 560b5dfd 0
When running the LVM2 testsuite on 32-bit kernel, there are unkillable
processes stuck in the kernel consuming 100% CPU:
blkid R running 0 2005 1409 0x0004
ce009d00 0082 ffcf c11280ba 0060 560b5dfd 3111 00fe41cb
ce009d00 d51cfeb0
11 matches
Mail list logo