Re: Masking mount units

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mo, 11.11.24 08:34, Phillip Susi (phill@xxxxxxxxxxxx) wrote:

> Lennart Poettering <lennart@xxxxxxxxxxxxxx> writes:
>
> >> I'm reading between the lines a bit, but my guess is that libparted
> >> always opens the device writable in case you start issuing actual
> >> partitioning commands.
> >
> > That sounds like a bug though. They should open the device for write
> > only when they need to make changes.
>
> It opens all of the partitions in write mode in order to flush the
> cache.  I believe this was put in as a workaround to the Linux cache
> coherency problem that caused reads through the whole disk not to see the
> recently written filesystem superblock after running mkfs.

the BLKFLSBUF ioctl() works fine on block device fds open for read only.

> >> To support "parted print doesn't trigger udev
> >> events", I think you'd have to change libparted so that it opens the
> >> device for read first (potentially with a shared lock) and then
> >> reopens it for write (with an exclusive lock) when needed (e.g. when
> >> using the mkpart command in the interactive session). Without that, I
> >> think you're always going to need workarounds such as masking mount
> >> units.
> >
> > Yeah, what you are proposing sounds like it is the way to go indeed,
> > if parted really is not doing this already right now.
>
> The bsd lock only *delays* the auto mounting, it does not prevent it, so
> it seems that there is nothing libparted can do to prevent auto mounting
> other than getting rid of the cache flushes and accepting the old
> problem with cache cohernecy.

I am not following anymore. As *long* *as* *the* lock is taken the
auto mounting doesn't happen. Once you release the lock then
everything will be reprobed and work as it always worked, including
auto-mounting.

But the time window how long auto mounting shall not take place is
under parted's control: as long as it keeps the lock taken,
automounting won't take place.

> I thought that perhaps a runtime override of RequiredBy=local-fs.target
> and WantedBy=dev-sdb1.device ( equivalent to the noauto mount option in
> /etc/fstab ) would do it, but apparently you can't actully set most
> properties at runtime.  Why is that?
>
> Also, again, why does a udev CHANGE event on sdb1.device trigger auto
> mount?  Shouldn't that only be done for ADD?

So that newly placed file systems can be probed and the rest of the
stack can learn about them.

But I am really puzzled by what the whole misunderstanding here is. Do
you understand what a "lock" in computer science means? I have the
suspicion you don't? As long as you keep the lock on the block device
you basically have exclusive access at lesat in regards to everyone
else following the lock protocol, of which udev is one.

Lennart

--
Lennart Poettering, Berlin