linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Weidemann <kwe-lnx@postn.eu>
To: "Pali Rohár" <pali.rohar@gmail.com>
Cc: Jan Kara <jack@suse.cz>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: udf: Prevent write-unsupported filesystem to be remounted read-write
Date: Mon, 14 Jan 2019 17:26:45 +0100	[thread overview]
Message-ID: <1aeb551f-827e-4e4d-b373-c6f9901a798e@postn.eu> (raw)
In-Reply-To: <20190114151242.vrspcgld3n645qez@pali>

On Monday 14 January 2019 at 16:12 Pali Rohár wrote:
> So you should not use -m dvd for hard disks.
>
> Also DVDs have block size of 2048 bytes and UDF mandates that medium
> block size matches UDF block size. Linux versions >= 4.11 do not have
> problems with it, but other operating systems enforce that rule.
>
> So you should not use -b 512 for DVD medias.

Hi Pali,

thanks for your pointers.
Interestingly enough, I chose that combination based on my test that
resulted in all (to me) relevant OSes (various Windows variants and my
set of Linux boxes) handling the resulting file system the way I
expected them to.
Choosing the bigger size of 2048 resulted in either issues when mounting
on Windows and/or having to pass a specific block size when mounting
under Linux, if I remember it correctly. It might have to do with the
block size of the block device under it. I think the point of using `-m
dvd` was to make the file system mount as read-only by default, though
it's been some months. I do remember checking what exactly `-m dvd` did
other than setting the access-type of the fs, but I must admit I don't
remember the result of that.

The main issue is, however, unaffected by this. I do agree that a
tune2fsque sort of tool as part of udftools would greatly improve the
situation.

  reply	other threads:[~2019-01-14 16:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <124cc6ea-ca79-20f2-651e-c2f909729ac0@gmx.de>
2019-01-14  0:33 ` udf: Prevent write-unsupported filesystem to be remounted read-write Kevin Weidemann
2019-01-14 10:30   ` Jan Kara
2019-01-14 12:00     ` Pali Rohár
2019-01-14 12:30       ` Jan Kara
2019-01-15  3:07         ` Michael Sabolish
2019-01-15  8:31           ` Pali Rohár
2019-01-15  8:41             ` Jan Kara
2019-01-15  8:48               ` Pali Rohár
2019-01-15  9:45                 ` Jan Kara
2019-01-15 10:50                   ` Pali Rohár
2019-01-15 11:15                     ` Jan Kara
2019-01-14 15:12     ` Pali Rohár
2019-01-14 16:26       ` Kevin Weidemann [this message]
2019-01-22 13:22     ` Jan Kara
2019-01-23 20:29       ` Kevin Weidemann

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=1aeb551f-827e-4e4d-b373-c6f9901a798e@postn.eu \
    --to=kwe-lnx@postn.eu \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pali.rohar@gmail.com \
    /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).