From: Roman Mamedov <rm@romanrm.net>
To: Timofey Titovets <nefelim4ag@gmail.com>
Cc: Duncan <1i5t5.duncan@cox.net>, linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] Btrfs: compression must free at least PAGE_SIZE
Date: Sun, 21 May 2017 22:30:41 +0500 [thread overview]
Message-ID: <20170521223041.4aa7d0f6@natsu> (raw)
In-Reply-To: <CAGqmi77_iaZC0f0BsGWVAzgZnNRvWTHkxvnP=risHa33NGPhGA@mail.gmail.com>
On Sun, 21 May 2017 19:54:05 +0300
Timofey Titovets <nefelim4ag@gmail.com> wrote:
> Sorry, but i know about subpagesize-blocksize patch set, but i don't
> understand where you see conflict?
>
> Can you explain what you mean?
>
> By PAGE_SIZE i mean fs cluster size in my patch set.
This appears to be exactly the conflict. Subpagesize blocksize patchset would
make it possible to use e.g. Btrfs with 4K block (cluster) size on a MIPS
machine with 64K-sized pages. Would your checking for PAGE_SIZE still be
correct then?
> So if and when subpage patch set would merged, PAGE_SIZE should be
> replaced with sector size, and all continue work correctly.
I guess Duncan's question was why not compare against block size from the get
go, rather than create more places for Chandan to scour through to eliminate
all "blocksize = pagesize" assumptions...
--
With respect,
Roman
next prev parent reply other threads:[~2017-05-21 17:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-20 16:49 [PATCH v2 0/2] Btrfs: compression fixes Timofey Titovets
2017-05-20 16:49 ` [PATCH v2 1/2] Btrfs: lzo.c pr_debug() deflate->lzo Timofey Titovets
2017-05-20 16:49 ` [PATCH v2 2/2] Btrfs: compression must free at least PAGE_SIZE Timofey Titovets
2017-05-20 17:14 ` Kai Krakow
2017-05-20 18:30 ` Timofey Titovets
2017-05-21 1:38 ` Duncan
2017-05-21 16:54 ` Timofey Titovets
2017-05-21 17:30 ` Roman Mamedov [this message]
2017-05-21 22:32 ` Timofey Titovets
2017-05-22 9:44 ` Duncan
2017-05-23 6:05 ` kbuild test robot
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=20170521223041.4aa7d0f6@natsu \
--to=rm@romanrm.net \
--cc=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
--cc=nefelim4ag@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).