On Wed, Nov 26, 2014 at 01:51:57PM +1100, Paul Ripke wrote: > On Tue, Nov 25, 2014 at 09:25:02AM +0100, Martin Husemann wrote: > > On Tue, Nov 25, 2014 at 01:22:00PM +1100, Paul Ripke wrote: > > > slave:ksh$ find /home/tmp > /dev/null > > > find: /home/tmp/badfile: Bad file descriptor > > > > Is that FS on raidframe? > > > > I saw something like this once and blamed it on a failing disk (which > > did show SMART errors shortly afterwards), i.e. I assumed the two > > halfs of the raid0 would eroneously have had inconsistent data. > > It is raidframe; however, this is about the 4th file I've lost, and in > all cases it has been a corrupted inode... if it was a more general > failing disk, I'd expect to see corruption in eg. postgres, gzip files, > even mp3's or avi's. > > Just to be safe, I'm running the below now; the filesystem is still > live, so I know it won't be 100% clean, but it'll be interesting to > see what it spits out. > > ksh$ cmp -l /dev/rwd0a /dev/rwd1a 65536 65536
Well, the cmp completed, and displays no differences (well, one sector that must've been an in-flight write, since a second run over those offsets was clean). This is looking like a filesystem bug/race. Time to spin up a VM and see if I can reproduce it... -- Paul Ripke "Great minds discuss ideas, average minds discuss events, small minds discuss people." -- Disputed: Often attributed to Eleanor Roosevelt. 1948.
