On 26/07/2014 20:07, Theodore Ts'o wrote:
On Sat, Jul 26, 2014 at 11:07:59PM +0000, Vlad Dobrotescu wrote:
If this isn't the proper place for this question, please point me in
the right direction.
I couldn't find any description on Ext4's behaviour when mounted
with errors=continue and external journal if the journal block device
is unavailable at mount time (or becomes unavailable at some point).
I would be using CentOS 7 (kernel 3.10.0-123.4.4.el7 x86_64) and
(probably) full data journaling on a SSD. Can someone help?
So there are two different questions.
If you use errors=continue, there is the chance that the file system
inconsistencies that discovered could cause further file system
damage, which might lead to the loss or corruption of data files
written earlier. So it's not really recommended for most purposes,
unless you have some scheme where you are monitoring dmesgs and having
some strategy to deal with detected file system errors, or when the
system absolutely, positively must continue running, and this is more
important than potential data loss.
If the journal block device is not present then the file system can't
be mounted, and if the system was uncleanly shut down you won't be
able to recover from the unclean shutdown by replaying the journal.
If the journal block device is *gone*, it is possible to remove the
external journal block device, and then force a file system repair,
but if this happens after an unclean shutdown, you may very well lose
data.
Cheers,
- Ted
Sorry if this is a duplicate, but the "Followup" didn't seem to work for me
Thanks for the quick and detailed answer. If I understand it correctly,
the errors= option has nothing to do with journaling, but only with FS
consistency issues (which can be caused by a vanished journal, but also
by other events), while the mounting itself fails in the absence of the
device specified for external journaling, with no fall-back alternative.
Right?
Vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
