Re: [Bisected] Corruption of root fs during git bisect of drm system hang

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

 



On 2013.07.19 at 14:41 +0200, Stefan Ring wrote:
> > I've bisected this issue to the following commit:
> >
> >  commit cca9f93a52d2ead50b5da59ca83d5f469ee4be5f
> >  Author: Dave Chinner <dchinner@xxxxxxxxxx>
> >  Date:   Thu Jun 27 16:04:49 2013 +1000
> >
> >      xfs: don't do IO when creating an new inode
> >
> > Reverting this commit on top of the Linus tree "solves" all problems for
> > me. IOW I no longer loose my KDE and LibreOffice config files during a
> > crash. Log recovery now works fine and xfs_repair shows no issues.
> >
> > So users of 3.11.0-rc1 beware. Only run this version if you have
> > up-to-date backups handy.
> 
> What I miss in this thread is a distinction between filesystem
> corruption on the one hand and a few zeroed files on the other. The
> latter may be a nuisance, but it is expected behavior, while the
> former should never happen, period, if I'm not mistaken.

Well, it is natural that fs developers at first try to blame userspace.
Unfortunately it turned out that in this case there is filesystem
corruption. (Fortunately this normally happens only very rarely on rc1
kernels).

-- 
Markus

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs




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

  Powered by Linux