Date: Wed, 01 Apr 2015 11:56:52 +0300 From: Artem Kuchin <artem@artem.ru> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-fs@freebsd.org Subject: Re: Little research how rm -rf and tar kill server Message-ID: <551BB2D4.6070505@artem.ru> In-Reply-To: <20150401083609.GX2379@kib.kiev.ua> 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> <20150401083609.GX2379@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
01.04.2015 11:36, Konstantin Belousov пишет: >> >>>> 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. I assumed what was not :) Did not know about mount -v at that time. > > 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. Yes, I know it is a bad way to go, but since fsck was dirty because of the hang bug the buffers were empty before reboot, so, basically sync was complete just clean flag not set. It happened before and fsck only found leaky inodes.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?551BB2D4.6070505>