xfs
[Top] [All Lists]

Re: Swapfiles broken on XFS.

To: Nigel Cunningham <ncunningham@xxxxxxxxxxxxxxxxxxxxx>
Subject: Re: Swapfiles broken on XFS.
From: Karol Kozimor <sziwan@xxxxxxxxxxx>
Date: Fri, 9 Jan 2004 17:01:28 +0100
Cc: XFS list <linux-xfs@xxxxxxxxxxx>, swsusp-devel <swsusp-devel@xxxxxxxxxxxxxxxxxxxxx>
In-reply-to: <1073620506.3790.21.camel@laptop-linux>
Mail-followup-to: Nigel Cunningham <ncunningham@xxxxxxxxxxxxxxxxxxxxx>, XFS list <linux-xfs@xxxxxxxxxxx>, swsusp-devel <swsusp-devel@xxxxxxxxxxxxxxxxxxxxx>
References: <1073620506.3790.21.camel@laptop-linux>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4.1i
Thus wrote Nigel Cunningham:
> mm/page_io:722 uses swapf->i_sb->s_blocksize to determine the number of
> blocks required to store a page. This method is also in Software
> Suspend's swapfile support. Karol emailed me yesterday saying swapfile
> support in Suspend seemed to be broken, and I've tracked it down to the
> fact that (at least on a test 192MB XFS partition with a 98MB swapfile
> on it), s_blocksize is set to 4096 while the blocksize actually appears
> to be 512. The means Suspend only gets 12.5% of the way through writing
> the image before finding it has run out of space. I don't know how the
> system would cope with the descrepancy.

I seem to have the answer now: Bad Things^TM. Actually, the test partition
I set up for that ended up corrupted beyond mounting (superblock was
probably overwritten). Running xfs_repair helped a bit (the whole kernel
tree landed in lost+found and the directory structure was shattered, but
the files themselves did not show any corruption).
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@xxxxxxxxxxx


<Prev in Thread] Current Thread [Next in Thread>