From: Nigel Cunningham <ncunningham@users.sourceforge.net>
To: Christoph Hellwig <hch@infradead.org>
Cc: XFS list <linux-xfs@oss.sgi.com>,
Karol Kozimor <sziwan@hell.org.pl>,
swsusp-devel <swsusp-devel@lists.sourceforge.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Swapfiles broken on XFS.
Date: Sat, 10 Jan 2004 10:41:45 +1300 [thread overview]
Message-ID: <1073684450.4596.55.camel@laptop-linux> (raw)
In-Reply-To: <1073679200.4566.12.camel@laptop-linux>
[-- Attachment #1: Type: text/plain, Size: 1595 bytes --]
Hi.
Actually, i_sb->s_blocksize and blocksize_bits both reflect a block size
of 4096 too, so that didn't help. What does help is using blksize_size.
I'll prepare a patch for Karol and I to try before submitting it to
LKML.
Regards,
Nigel
On Sat, 2004-01-10 at 22:13, Nigel Cunningham wrote:
> Hi again.
>
> Perhaps I wasn't clear enough.
>
> Both the page_io and Suspend can cope fine with block size < 4096. The
> issue is where they get the information from as to how many blocks per
> page they actually need to use when called brw_page. At the moment, they
> both assume that i_sb->s_blocksize and blocksize_bits is the place to
> go. What you're saying sounds right to me. They should both be looking
> at i_blkbits and i_blksize in the struct inode, shouldn't they? I'll
> make the change, test and submit a patch to LKML.
>
> Regards,
>
> Nigel
>
> On Sat, 2004-01-10 at 05:16, Christoph Hellwig wrote:
> > On Fri, Jan 09, 2004 at 04:55:09PM +1300, Nigel Cunningham wrote:
> > > It appears to me that a swapfile on an XFS filesystem will not work, at
> > > least some of the time.
> >
> > XFS sets s_blocksize to the filesystem blocksize and bdev->bd_block_size /
> > i_blkbits to the XFS sector size. The first would be 4096 in your
> > case and the latter 512. We cannot set a bigger device block size because
> > XFS log writes are in 512b units.
> >
> > I don't think the swap code should do any assumptions about any relation
> > of the above two.
--
My work on Software Suspend is graciously brought to you by
LinuxFund.org.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
prev parent reply other threads:[~2004-01-09 21:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1073620506.3790.21.camel@laptop-linux>
[not found] ` <20040109161653.A25678@infradead.org>
2004-01-09 20:13 ` Swapfiles broken on XFS Nigel Cunningham
2004-01-09 21:41 ` Nigel Cunningham [this message]
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=1073684450.4596.55.camel@laptop-linux \
--to=ncunningham@users.sourceforge.net \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@oss.sgi.com \
--cc=swsusp-devel@lists.sourceforge.net \
--cc=sziwan@hell.org.pl \
/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.