<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 9, 2016 at 1:08 AM, Dave Chinner <span dir="ltr"><<a href="mailto:david@fromorbit.com" target="_blank">david@fromorbit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Apr 08, 2016 at 12:06:35PM +0200, Jan Tulak wrote:<br>
> On Fri, Apr 8, 2016 at 2:09 AM, Dave Chinner <<a href="mailto:david@fromorbit.com">david@fromorbit.com</a>> wrote:<br>
><br>
> > On Thu, Mar 24, 2016 at 12:15:34PM +0100, <a href="mailto:jtulak@redhat.com">jtulak@redhat.com</a> wrote:<br>
> > > From: Jan Tulak <<a href="mailto:jtulak@redhat.com">jtulak@redhat.com</a>><br>
> > ><br>
> > > Unify mkfs.xfs behaviour a bit and never truncate files. If the user<br>
> > > is trying to mkfs an existing file, we don't want to destroy anything<br>
> > > he did with the file before (sparse file, allocations...)<br>
> ><br>
> > Why not? We do that with discard-by-default to block devices,<br>
> > O_TRUNC is exactly the same situation with a file - we completely<br>
> > re-initialise the file from a known state if mkfs has been asked to<br>
> > create the file.<br>
> ><br>
> But AFAIK, we don't zero-out entire spindle devices,<br>
<br>
</span>Unless the controller above them supports discard or whatever<br>
implementation the storage protocol uses (e.g. UNMAP or WRITE_SAME).<br>
e.g, the "spindle devices" often are big raid arrays that are using<br>
thin provisioning, compression and dedupe internally, so running<br>
discard on them does make a significant difference to their<br>
behaviour.<br>
<span class=""><br>
> we don't ask if the drive skips some blocks (i.e. because they are bad),<br>
<br>
</span>That's irrelevant to the issue at hand.<br>
<span class=""><br>
> and we don't care<br>
> about what an underlaying layer (like LVM) did with the block device.<br>
<br>
</span>Actually, we do, because users care about their storage stack doing<br>
sane management operations automatically.<br>
<br>
That's why we issued a discard - it tells the underlying devices to<br>
re-initialise the storage on this device *if they care about such<br>
things*. Stuff like thinly provisioned devices rely on mkfs<br>
behaviour like this to recycle used storage efficiently and<br>
transparently. The user expects things to "just work" and this is<br>
one of those things that makes it "just work".<br>
<span class=""><br>
> From<br>
> this point of view, we shouldn't care about the file either.<br>
><br>
> I can be missing something, though.<br>
<br>
</span>I think you're missing the fact that we don't know what the<br>
*underlying storage* cares about, so we need to tell them in some<br>
way that a device or image file is being re-initialised from<br>
scratch. Whether that is by truncating the image file (so the<br>
filesytem can issue discards on the now unused space) or by issuing<br>
discard ioctls ourselves, it really doesn't matter. The key point is<br>
that we have a mechanism that allows us to notify the underlying<br>
storage of the "this is re-initialised storage" intent of mkfs.<br>
<br>
So from that perspective, the O_TRUNC behaviour should remain.<br>
<div class="HOEnZb"><div class="h5"><br>
Cheers,<br>
<br>
Dave.<br>
--<br>
Dave Chinner<br>
<a href="mailto:david@fromorbit.com">david@fromorbit.com</a></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">All right​, I will keep the O_TRUNC there. However, should it truncate the file every time, or should we offer a way how to avoid the file truncating? Until now, mkfs behaved differently based on whether -d file was given, or not. Your explanation suggests that we should truncate every time, right?</div></div></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">​Cheers,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Jan​</div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Jan Tulak<br></div><a href="mailto:jtulak@redhat.com" target="_blank">jtulak@redhat.com</a> / <a href="mailto:jan@tulak.me" target="_blank">jan@tulak.me</a></div></div></div></div>
</div></div>