Re: [PATCH 15/19] mkfs: don't treat files as though they are block devices

Jan Tulak
2016-04-22T07:46:57Z

[-- Attachment #1.1: Type: text/plain, Size: 2086 bytes --]

On Thu, Apr 21, 2016 at 10:13 PM, Eric Sandeen <sandeen@sandeen.net> wrote:

>
>
> On 4/21/16 8:43 AM, Jan Tulak wrote:
> > On Thu, Apr 21, 2016 at 11:39 AM, Jan Tulak <jtulak@redhat.com <mailto:
> jtulak@redhat.com>>wrote:
> >
> > From: Dave Chinner <dchinner@redhat.com <mailto:dchinner@redhat.com
> >>
> >
> > THIS PATCH HAS KNOWN ISSUES - it fails xfs/206 and xfs/216 tests, as
> it
> > shrinks a file instead just not using it entirely, when -d size is
> used.
> >
> >
> > ​So the shrinking is happening here:
> > 3127 /*
> > 3128 * If the data area is a file, then grow it out to its final
> size
> > 3129 * so that the reads for the end of the device in the mount
> code
> > 3130 * will succeed.
> > 3131 */
> > 3132 if (xi.disfile && ftruncate64(xi.dfd, dblocks * blocksize) <
> 0) {​
> >
> >
> > Before the patch, xi.disfile was 0 and so it didn't shrink the file
> > to the size of the new FS. Now, what is the correct solve to this?
> > Tests are written for the old behaviour, but this shrinking seems to
> > be an intentional thing. It seems that the FS works ok even when this
> > truncating is not applied, so I think that I should remove this chunk
> > (or change it to xi.dcreate=1 only), and keep the old behaviour.
> >
> > What do you think about it, guys?
>
> Can't remove it; that would break the other side of things, if you try
> to mkfs.xfs -d size=2g on an existing 1g file... mount tries to do
> IO to the last block, and if it's not truncated out, that will fail
> (as the comment says).
>
> I suppose the simple way to fix it is to only truncate up, never down.
>
> i.e. truncate to max(dblocks * blocksize, st_size) or
> if (xi.disfile && st_size < dblocks * blocksize) { truncate ... }
>

All right, it seems that I should have read the man page, and not just
look on the first sentence or two... <emoticon of me hitting a wall with
my head repeatedly>.

Now it works, thanks.

Jan

--
Jan Tulak
jtulak@redhat.com / jan@tulak.me

[-- Attachment #1.2: Type: text/html, Size: 3646 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]