Re: unexpected truncated files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2020 Apr 04, Filipe Manana wrote:
> On Sat, Apr 4, 2020 at 8:52 PM Johannes Hirte
> <johannes.hirte@xxxxxxxxxxxxx> wrote:
> >
> > While testing with the current 5.7 development kernel, I've encountered
> > some strange behaviour. I'm using Gentoo linux, and during updating the
> > system I got some unexpected errors. It looked like some files were
> > missing. Some investigations showed me, that files from shortly
> > installed packages were truncated to zero. So for example the config
> > files for apache webserver were affected. I've reinstalled apache,
> > verified that the config was ok and continued the system update with the
> > next package. After this, the apache config files were truncated again.
> > I've found several files from different packages that were affed too,
> > but only text files (configs, cmake-files, headers). Files which were
> > writen, are truncated by some other write operation to the filesystem.
> >
> > I'm not sure, if this is really caused by btrfs, but it's the most
> > obvious candidate. After switching back to 5.6-kernel, the truncation
> > stopped und I was able to (re-)install the packages without any trouble.
> >
> > Has anyone ideas what could cause this behaviour?
> 
> It's likely due to file cloning.
> 
> I found this out yesterday but hadn't sent a patch yet, was waiting
> for monday morning.
> I've just sent the patch to the list:
> https://patchwork.kernel.org/patch/11474453/
> 
> Since you are only getting this with small files, it's likely the
> cloning of inline extents causing it, due to some changes in 5.7 that
> changed the file size update logic.
> 
> Can you try it?
> 
> Thanks.

Yes, this was it. Installing the second package for triggering the
truncation was a coincidence. Installing the first package (appache
here) and rebooting triggered the error reliable. With portage (the package
manager from Gentoo) everything is compiled and installed to a a
location on /tmp. After this, the content is copied to the target
location and seems to be done with cloning. With your patch the problem
doesn't occur anymore.

-- 
Regards,
  Johannes Hirte




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux