Re: [PATCH V18 00/18] Allow I/O on blocks whose size is less than page size

[Chandan Rajendra <chandan@linux.vnet.ibm.com>]

On Wednesday 27 Apr 2016 19:15:34 David Sterba wrote:
> On Tue, Apr 26, 2016 at 08:48:49PM +0530, Chandan Rajendra wrote:
> > On Tuesday 26 Apr 2016 14:54:46 Filipe Manana wrote:
> > > Hi Chandan,
> > > 
> > > What does it mean the tests don't pass? Is there absolutely no code
> > > changes for scrub and compression, or there is but still needs more
> > > working, or what?
> > 
> > Hi Filipe,
> > 
> > The patches that have been sent have no changes made with respect to
> > either
> > scrub or compression.
> > 
> > > What happens if, when one is using block size < page size, and enables
> > > compression on a single file (i.e. fs not mounted with -o compress or
> > > force-compress), we start writing and read to the file? Does it result
> > > in the syscalls failing with -EIO or some other error, does it result
> > > in crashes (BUG_ON(), etc), dues it result in transparently falling
> > > back to non compression mode, or what happens exactly?
> > 
> > With the current patchset, reading/writing to a compressed file in
> > (block size == page size) scenario works fine. However reading/writing to
> > a
> > compressed file in (block size < page size) results in crashes.
> 
> Lack of support for compression was pre-agreed but chrashes do not seem
> ok to me, if there are EINVAL or EOPNOTSUPP erros that would be
> acceptable for the first version I think. We will run fstests with this
> patchset so if a test fails then we can see if it was due to
> compression, but a crash would make testing tedious, manual test
> exception needed etc.

In the next revision of the patchset, I will make sure the code returns
EINVAL or EOPNOTSUPP in case I/O is performed on compressed files in
subpage-blocksize scenario.

-- 
chandan