Date: Fri, 3 Mar 2017 02:21:13 +0300 From: Subbsd <subbsd@gmail.com> To: Peter Jeremy <peter@rulingia.com> Cc: freebsd-current Current <freebsd-current@freebsd.org>, freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: effect of strip(1) on du(1) Message-ID: <CAFt_eMom-C68Fo4NR8HVqPBUwKTKYUvCy2seXDg3hzOOU_f=Vw@mail.gmail.com> In-Reply-To: <20170302230416.GK4503@server.rulingia.com> References: <CAFt_eMqjO3ihJ925J7KTdRm2cZiPZmC0v0KS0P8TQ=OQA5s=Wg@mail.gmail.com> <20170302230416.GK4503@server.rulingia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 3, 2017 at 2:04 AM, Peter Jeremy <peter@rulingia.com> wrote: > On 2017-Mar-02 22:29:46 +0300, Subbsd <subbsd@gmail.com> wrote: >>During some interval after strip call, du will show 512B for any file. >>If execute du(1) after strip(1) without delay, this behavior is reproduced 100%: > > What filesystem are you using? strip(1) rewrites the target file and du(1) > reports the number of blocks reported by stat(2). It seems that you are > hitting a situation where the file metadata isn't immediately updated. > > -- > Peter Jeremy Got it. My filesystem is ZFS. Looks like when ZFS open and write data to file, we get wrong number of blocks during a small interval after writing. Thanks for pointing this out!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFt_eMom-C68Fo4NR8HVqPBUwKTKYUvCy2seXDg3hzOOU_f=Vw>