linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali.rohar@gmail.com>
To: "Jan Kara" <jack@suse.cz>, "Steve Kenton" <skenton@ou.edu>,
	"Vojtěch Vladyka" <rain@vojtechvladyka.cz>,
	linux-fsdevel@vger.kernel.org
Subject: UDF & open integrity type
Date: Mon, 26 Feb 2018 20:32:25 +0100	[thread overview]
Message-ID: <20180226193225.k2og3lu6dw46h74w@pali> (raw)

[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]

Hi! After doing more experiments with UDF Integrity Type stored in UDF
Logical Volume Integrity Descriptor, it looks like for me that kernel
udf fs driver does not implement handling of open integrity correctly.

Open Integrity Type (except on VAT disk) mean that filesystem was last
time improperly unmounted, e.g. removable media was disconnected when
some write operation was in progress or when umount on Linux was not
issued.

Filesystem with Open Integrity type should be checked for error and
ideally also repaired prior next write (or maybe also read) operations.
Probably Open Integrity type can be treated on Linux as Dirty bit in FAT
filesystem.

But it looks like that kernel udf driver automatically change Open
Integrity Type to Closed when doing unmount, even when Type was Open
prior to UDF mount. For me it does not seem to be correct as kernel
itself does not implement any repair/recovery for UDF filesystem and
automatically lost any information that chkdsk/fsck should be run.

As there is planned fsck.udf, it is really important to have correct
information of successful umount command stored in filesystem itself.
This can help fsck to know last state of filesystem, like Dirty bit in
FAT or clean state of journal for ext*.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

             reply	other threads:[~2018-02-26 19:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-26 19:32 Pali Rohár [this message]
2018-02-27 18:01 ` UDF & open integrity type Jan Kara
2018-02-27 19:40   ` Pali Rohár
2018-02-28  9:54     ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180226193225.k2og3lu6dw46h74w@pali \
    --to=pali.rohar@gmail.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=rain@vojtechvladyka.cz \
    --cc=skenton@ou.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).