On 16.12.2012 11:30, Matthias Schniedermeyer wrote: > On 16.12.2012 09:16, Dave Chinner wrote: > > > > Like most amateurs you've jump to the obvious conclusion without > > considering all the other possibilities that could give the same > > result. > > I have a test-case, so you can cut out the amateur. > Partition is 100GB at the beginning of a 1,5TB SATA HDD connected by > USB3 enclosure: > Machine has 4GB of memory and is running a vanilla 3.7.0 kernel. > > mkfs.xfs -l size=1024b -s size=4096 /dev/sdb1 > mount /dev/sdb1 /mnt > mkdir /mnt/a > cd /mnt/a > for dat in `seq 1 40`; do dd if=/dev/zero of=$dat bs=1k count=900k ; done > > Then i started a timer and waited for 5 minutes. > Then i yanked out the cable, my machine was writing to the 24th file at > that point. > > umount /mnt > <replug cable> > mount /dev/sdb1 /mnt > ls -l /mnt > <In words: Nothing there, not even a> > > I tried it 3 times, all times with the same result that not even "a" was > there. > > In the last run i did a `ls -l /mnt/a` at the 4 minute-point, it showed > several files with 900MB. And boy is it unsafe to use XFS currently. Modifed test-case. Same as above, except for this loop: for dat in `seq 1 10`; do dd if=/dev/zero of=$dat bs=1k count=900k ; done After it ran through i waited 5 minutes, IOW there were 5 minutes of nothing going on. Yank out cable, yada, yada, yada. Result: Same as above. This proves(at last for the amateuer in me) that it is the same bug as the OP had. Variant 3. Same as 2, but with a 'sync' after the for-loop. After 'sync' returns, i immediatly yank out the cable. After replugging the result is as expect, the directroy and all files exist. So as far as i can tell, currently there is a 'sync' missing somewhere. It it is at least in kernels 3.6 & 3.7, maybe 3.5. Could it be the removal of pdflush? -- Matthias _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
