On 4/21/16 8:43 AM, Jan Tulak wrote: > On Thu, Apr 21, 2016 at 11:39 AM, Jan Tulak <jtulak@xxxxxxxxxx <mailto:jtulak@xxxxxxxxxx>>wrote: > > From: Dave Chinner <dchinner@xxxxxxxxxx <mailto:dchinner@xxxxxxxxxx>> > > 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 ... } -Eric > Cheers, > Jan > > > > -- > Jan Tulak > jtulak@xxxxxxxxxx <mailto:jtulak@xxxxxxxxxx> / jan@xxxxxxxx <mailto:jan@xxxxxxxx> > > > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
