> -----Original Messages----- > From: "Theodore Y. Ts'o" <tytso@xxxxxxx> > Sent Time: 2018-03-20 12:12:31 (Tuesday) > To: "Jidong Xiao" <0121167@xxxxxxxxxxxx> > Cc: "Andreas Dilger" <adilger@xxxxxxxxx>, linux-ext4@xxxxxxxxxxxxxxx, "Jidong Xiao" <jidong.xiao@xxxxxxxxx> > Subject: Re: No data blocks at all in my ext4 journal > > First of all, can you try upgrading to the very latest version of > e2fsprogs. You are using a very ancient version of e2fsprogs > (1.42.13.wc5) which has also been patched for Lustre. If you use > e2fsprogs 1.44.0, then at least we'll be testing on roughly the same > version of e2fsprogs, just in case the issue is caused by how debugfs > logdump works. > > Secondly, the file system is a really ancient one, with a very tiny > journal (32M). These days we use a default of a much larger journal, > which is shown to provide much better performance. (See section 4.1 > of [1].) > > [1] https://www.usenix.org/system/files/conference/fast17/fast17-aghayev.pdf > > It looks liket you are looking at a live file system, and it's possible > that due to a combination of a small journal, journal wrapping, and an > old version of debugfs/logdump is causing the confusion. > > So the other I would ask is that you try is to experiment on something > on your live root file system, so you can run a more controlled > experiment. To that end, please install kvm-xfstests or > gce-xfstests[2]. Quick start instructions for kvm-xfstest are > available at [3]. > > > [2] https://thunk.org/gce-xfstests > [3] https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md > > This will allow you to run a controlled experiment, something like this: > > % kvm-xfstests --kernel /build/ext4-4.4 shell > .... > root@kvm-xfstests:~# mke2fs -Fq -t ext4 /dev/vdc > /dev/vdc contains a ext4 file system > last mounted on Mon Jan 1 10:52:47 2018 > root@kvm-xfstests:~# mount /dev/vdc > root@kvm-xfstests:~# cp -r xfstests /vdc ; sync > root@kvm-xfstests:~# C-a x <==== type control-A, followed by x to abort QEMU > QEMU: Terminated > > % debugfs -R "logdump -ac" kvm-xfstests/disks/vdc > /tmp/logdump.out > debugfs 1.44.0 (7-Mar-2018) > % less /tmp/logdump.out > > > This means you're using a standard test environment. You can use a > kernel built from upstream sources (detailed instructions for doing > this can be found at [4]), and the kvm-xfstests environment uses a > standard Debian environment with a stock e2fsprogs (no random > uncontrolled patches by Red Hat Enterprise Linux, and e2fsprogs with > random Lustre patches). You'll also be looking at a aborted file > system, as opposed to a file system which is live and potentially > being modified in real time while you look at it with your tools. > > [4] https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-xfstests.md > > This will be much easier than my trying to figure out what's going on > your system. I am suspicious of the version of e2fsprogs, I'm > suspicious of the fact that you are trying to examine a file system > while it is mounted and potentially being modified. etc. > > I can tell you that using a standard upstream 4.4 kernrel, and a > standard, unpatched, non-prehistoric version of e2fsprogs, probing a > file system which is aborted and not being modified while I look at > it, debugfs's logdump -ac shows me what I would expect. > > And if a RHEL kernel had a journal with the results that you had, if > you pulled the power, and the journal was replayed, it would corrupt > the whole file system. Since Red Hat Enterprise Linux users aren't > complained of completely destroyed file systems after a power failure, > I *know* your results must be somehow suspect. How, I'm not sure. > But instead of trying to debug your random environment, why don't you > try using a standard development/test environment? > > Regards, > > - Ted Hi, Ted, Thanks very much. I will follow your instructions and post update here. But my journal size is not 32MB, it is 128MB I think. 0x00008000=32768, mean 32768 blocks, and the block size is 4K, so 32768*4K=32K*4K=128MB. -Jidong
