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
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
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 uses
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 prevents
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
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 backing
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,
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
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
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.
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 ...
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
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
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
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
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
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 unsigned
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 ... or using
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 sounds like
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 supposed to be to
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 filesystems
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's what I
22 matches
Mail list logo
