Date: Wed, 1 Apr 2015 11:36:09 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Artem Kuchin <artem@artem.ru> Cc: freebsd-fs@freebsd.org Subject: Re: Little research how rm -rf and tar kill server Message-ID: <20150401083609.GX2379@kib.kiev.ua> In-Reply-To: <551BA987.4050708@artem.ru> References: <1427727936.293597.247070269.5CE0D411@webmail.messagingengine.com> <55196FC7.8090107@artem.ru> <1427730597.303984.247097389.165D5AAB@webmail.messagingengine.com> <5519716F.6060007@artem.ru> <1427731061.306961.247099633.0A421E90@webmail.messagingengine.com> <5519740A.1070902@artem.ru> <1427731759.309823.247107417.308CD298@webmail.messagingengine.com> <5519F74C.1040308@artem.ru> <20150331164202.GN2379@kib.kiev.ua> <551BA987.4050708@artem.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 01, 2015 at 11:17:11AM +0300, Artem Kuchin wrote: > 31.03.2015 19:42, Konstantin Belousov пишет: > > On Tue, Mar 31, 2015 at 04:24:28AM +0300, Artem Kuchin wrote: > >> 30.03.2015 19:09, Mark Felder пишет: > >> > > Syncer and sync(2) perform different kind of syncs. > This is strange. Did you see what > man 2 sync > said? > It specifically refers to syncer, implying that syncer does the same sync as > man 2 sync Code may select whatever strategy is useful in given situation, which implements the specified outcome. Kernel syncer uses the different code path in ffs_sync() for periodic updates to avoid uneccessary work already done by buffer write-outs (which is initiated by the same syncer thread, FWIW). There might be a bug, which I am trying to track. > > Is man page outdated or incorrect? > > Take the snapshot of > > sysctl debug.softdep before and after the situation occur to have some > > hints what is going on. > > > Will do tonight. Before, during and after the untaring. > > > > > Also, it makes sense to test the HEAD kernel after the r280763. Even if > > I end up with any fix, it probably would require r280760 as prerequisite. > > This is a working loaded server, i am afraid to test HEAD on it. That > make not be compatible > with the rest of the system. And actually, i don't know how to fetch > only kernel from HEAD :) Checkout head, do make kernel-toolchain buildkernel installkernel. > > > > > >> By the way: is there way to make sure that SU+J is really working? > >> Maybe it is disabled for some reason > >> and i don't know it. tunefs just shows stored setting, but, for example, > >> with dirty fs, journaling is not > >> working in reality. Any way to get current status of SU journaling? > > Your statement about 'dirty fs' makes no sense. > Maybe i misunderstood something > Here is the situation: > I have dirty shutdown, so fs is dirty > fsck started at boot but said something about unexpected inconsistency > and journal is not used > i stopped fsck > and made > mount -f -a > sh /etc/rc > to boot the server and make it work anyway > (later i shutdown it again and did fsck normally) > > As i understand journaling was disabled when i did mount -f -a > correct? No, you did not read what fsck wrote. The journal was thrown out and not used for fsck. It has no relation to the mount operation. To see if journaling is performed, see mount -v output. What you did is actually dangerous. If due to software bugs or firmware errors the on-disk metadata structure was corrupted, mounting the volume could cause run-time check and panic in the best case. In the ideal world, only inode or block leaks can occur, which is innocent to not be fixed by fsck, but there is difference between ideal and real world.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150401083609.GX2379>