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

[Jan Tulak]

On Thu, Apr 21, 2016 at 10:13 PM, Eric Sandeen <sandeen at 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 at redhat.com <mailto:
> jtulak at redhat.com>>wrote:
> >
> >     From: Dave Chinner <dchinner at redhat.com <mailto:dchinner at 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 at redhat.com / jan at tulak.me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20160422/a6a7a0da/attachment-0001.html>