All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Cc: fdmanana@gmail.com,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	"dsterba@suse.cz" <dsterba@suse.cz>, Chris Mason <clm@fb.com>,
	Josef Bacik <jbacik@fb.com>,
	chandan@mykolab.com
Subject: Re: [PATCH V18 00/18] Allow I/O on blocks whose size is less than page size
Date: Wed, 27 Apr 2016 19:15:34 +0200	[thread overview]
Message-ID: <20160427171534.GL29353@twin.jikos.cz> (raw)
In-Reply-To: <1812092.vCqY3YhCNW@localhost.localdomain>

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.

> > Same kind of question regarding scrub.
> 
> Scrub works fine for (block size == page size) scenario. However, Scrub ioctl
> returns -EINVAL for the case where block size != page size. Without the block
> size check, scrub might result in crashes.

EINVAL should be ok here.

  reply	other threads:[~2016-04-27 17:15 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-26 13:26 [PATCH V18 00/18] Allow I/O on blocks whose size is less than page size Chandan Rajendra
2016-04-26 13:27 ` [PATCH V18 01/18] Btrfs: subpage-blocksize: Fix whole page read Chandan Rajendra
2016-04-26 15:51   ` Josef Bacik
2016-04-27  5:24     ` Chandan Rajendra
2016-04-27 15:12       ` Josef Bacik
2016-04-26 13:27 ` [PATCH V18 02/18] Btrfs: subpage-blocksize: Fix whole page write Chandan Rajendra
2016-04-26 13:27 ` [PATCH V18 03/18] Btrfs: subpage-blocksize: Make sure delalloc range intersects with the locked page's range Chandan Rajendra
2016-04-26 13:27 ` [PATCH V18 04/18] Btrfs: subpage-blocksize: Define extent_buffer_head Chandan Rajendra
2016-04-26 13:27 ` [PATCH V18 05/18] Btrfs: subpage-blocksize: Read tree blocks whose size is < PAGE_SIZE Chandan Rajendra
2016-04-26 13:27 ` [PATCH V18 06/18] Btrfs: subpage-blocksize: Write only dirty extent buffers belonging to a page Chandan Rajendra
2016-04-26 13:27 ` [PATCH V18 07/18] Btrfs: subpage-blocksize: Allow mounting filesystems where sectorsize < PAGE_SIZE Chandan Rajendra
2016-04-26 13:27 ` [PATCH V18 08/18] Btrfs: subpage-blocksize: Deal with partial ordered extent allocations Chandan Rajendra
2016-04-26 13:27 ` [PATCH V18 09/18] Btrfs: subpage-blocksize: Explicitly track I/O status of blocks of an ordered extent Chandan Rajendra
2016-04-26 13:27 ` [PATCH V18 10/18] Btrfs: subpage-blocksize: btrfs_punch_hole: Fix uptodate blocks check Chandan Rajendra
2016-04-26 13:27 ` [PATCH V18 11/18] Btrfs: subpage-blocksize: Prevent writes to an extent buffer when PG_writeback flag is set Chandan Rajendra
2016-04-26 13:27 ` [PATCH V18 12/18] Revert "btrfs: fix lockups from btrfs_clear_path_blocking" Chandan Rajendra
2016-04-26 13:27 ` [PATCH V18 13/18] Btrfs: subpage-blocksize: Fix file defragmentation code Chandan Rajendra
2016-04-26 13:27 ` [PATCH V18 14/18] Btrfs: subpage-blocksize: extent_clear_unlock_delalloc: Prevent page from being unlocked more than once Chandan Rajendra
2016-04-26 13:27 ` [PATCH V18 15/18] Btrfs: subpage-blocksize: Enable dedupe ioctl Chandan Rajendra
2016-04-26 13:27 ` [PATCH V18 16/18] Btrfs: btrfs_clone: Flush dirty blocks of a page that do not map the clone range Chandan Rajendra
2016-04-26 13:27 ` [PATCH V18 17/18] Btrfs: subpage-blocksize: Make file extent relocate code subpage blocksize aware Chandan Rajendra
2016-04-26 13:27 ` [PATCH V18 18/18] Btrfs: subpage-blocksize: __btrfs_lookup_bio_sums: Set offset when moving to a new bio_vec Chandan Rajendra
2016-04-26 13:54 ` [PATCH V18 00/18] Allow I/O on blocks whose size is less than page size Filipe Manana
2016-04-26 15:18   ` Chandan Rajendra
2016-04-27 17:15     ` David Sterba [this message]
2016-04-28  4:31       ` Chandan Rajendra
2016-04-26 15:22 ` Josef Bacik
2016-04-27 17:18   ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160427171534.GL29353@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=chandan@linux.vnet.ibm.com \
    --cc=chandan@mykolab.com \
    --cc=clm@fb.com \
    --cc=fdmanana@gmail.com \
    --cc=jbacik@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.