Re: [systemd-devel] How to automount

Re: [systemd-devel] How to automount

[Johannes Pointner]

Hello Paul,

I'm using autofs to do the trick. It's working fine for me.

To get the umount working I use a timeout of 2 seconds, which seems to
be ok so far.

Regards,
Hannes


2015-09-23 21:28 GMT+02:00 Daniel. <danielhilst@gmail.com>:
> I agree with you that is intrinsically unworkable, if there is no physical
> media, how can it be umounted!? If anyone make this possible, maybe some
> day, in that day, umounting will be obsolete.
>
> Cheers,
> - dhs
>
> 2015-09-23 15:31 GMT-03:00 Paul D. DeRocco <pderocco@ix.netcom.com>:
>>
>> > From: Daniel. [mailto:danielhilst@gmail.com]
>> >
>> > I think that sync just flushes data to disk and umount clears
>> > the dirty bit. There is no sync.vfat that I know.
>>
>> That would seem to make auto-unmount (triggered by removal) an
>> intrinsically unworkable concept. Or is that only the case for FAT file
>> systems?
>>
>> --
>>
>> Ciao,               Paul D. DeRocco
>> Paul                mailto:pderocco@ix.netcom.com
>>
>
>
>
> --
> "Do or do not. There is no try"
>   Yoda Master
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: [systemd-devel] How to automount

[Mike Looijmans]

On 24-09-15 08:04, Johannes Pointner wrote:
> I'm using autofs to do the trick. It's working fine for me.
>
> To get the umount working I use a timeout of 2 seconds, which seems to
> be ok so far.


I am very very interested in how you got that to actually work. Please show us 
your configuration files and/or recipes and enlighten us!

So far, all I ever got autofs to accomplish was giving me a major headache.


Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

Re: [systemd-devel] How to automount

[Johannes Pointner]

I have to admit, I don't use systemd at the embedded system, but I use
the following files to do it for the usb flash drives:
/etc/auto.master:
+auto.master
/var/autofs /etc/auto.usb       --timeout=2

/etc/auto.usb:
usb1    -fstype=vfat,rw,sync,noatime,nodiratime,nodev,nosuid,noexec,uid=1000
   :/dev/usba
usb2    -fstype=vfat,rw,sync,noatime,nodiratime,nodev,nosuid,noexec,uid=1000
   :/dev/usbb

Furthermore I have a additional udev rule for the usb interfaces:
/etc/udev/rules.d/99-mount-usb-key.rules:
SUBSYSTEMS=="usb", SUBSYSTEM=="block", KERNELS=="1-1", ENV{USB_HUB}="usb2"
SUBSYSTEMS=="usb", SUBSYSTEM=="block", KERNELS=="2-1", ENV{USB_HUB}="usb1"

ENV{USB_HUB}=="usb1", SUBSYSTEM=="block", KERNEL=="sd[a-z]*", SYMLINK+="usba"
ENV{USB_HUB}=="usb2", SUBSYSTEM=="block", KERNEL=="sd[a-z]*", SYMLINK+="usbb"

But I also use automount on my desktop PC and there with systemd, but
no for a flash drives instead for cifs shares and this looks like
this:

/etc/autofs/aut.cifs-shares:
exchange -fstype=cifs,nosuid,rw,credentials=/home/h4nn35/.smbcredentials,dir_mode=0777,file_mode=0666
://server/exchange

/etc/autofs/auto.master:
+auto.master
/home/h4nn35/NetShares /etc/autofs/auto.cifs-shares --timeout=60 --ghost

I hope this helps.

2015-09-24 12:58 GMT+02:00 Mike Looijmans <mike.looijmans@topic.nl>:
> On 24-09-15 08:04, Johannes Pointner wrote:
>>
>> I'm using autofs to do the trick. It's working fine for me.
>>
>> To get the umount working I use a timeout of 2 seconds, which seems to
>> be ok so far.
>
>
>
> I am very very interested in how you got that to actually work. Please show
> us your configuration files and/or recipes and enlighten us!
>
> So far, all I ever got autofs to accomplish was giving me a major headache.
>
>
> Kind regards,
>
> Mike Looijmans
> System Expert
>
> TOPIC Embedded Products
> Eindhovenseweg 32-C, NL-5683 KH Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79
> Telefax: +31 (0) 499 33 69 70
> E-mail: mike.looijmans@topicproducts.com
> Website: www.topicproducts.com
>
> Please consider the environment before printing this e-mail
>
>
>
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: [systemd-devel] How to automount

[Paul D. DeRocco]

> From: Mantas Mikulenas [mailto:grawity@gmail.com] 
> 
> > I don't think there's any way to have something auto-unmount
> 
> There certainly is - udev has been unmounting unplugged 
> drives for many years. It's done by default.

If creating a udev mount rule automatically does the unmount, then the
simplest thing for me would probably be to do that, and have my
application do a sync after each user-initiated operation. That way, the
drive would remain mounted after the operation, so I could still poke
around on it while debugging, yet there would be no corruption when it's
removed. Thanks for the tip.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com

Re: [systemd-devel] How to automount

[Fred Ollinger]

This is in the package: udev-extraconf

On your system look here:

/etc/udev/rules.d/automount.rules

In this file, you'll find the following rules.

The second one auto unmounts.

SUBSYSTEM=="block", ACTION=="add"    RUN+="/etc/udev/scripts/mount.sh"

SUBSYSTEM=="block", ACTION=="remove" RUN+="/etc/udev/scripts/mount.sh"

SUBSYSTEM=="block", ACTION=="change", 
ENV{DISK_MEDIA_CHANGE}=="1" RUN+="/etc/udev/scripts/mount.sh"

________________________________________
From: yocto-bounces@yoctoproject.org <yocto-bounces@yoctoproject.org> on behalf of Paul D. DeRocco <pderocco@ix.netcom.com>
Sent: Tuesday, September 22, 2015 10:45 AM
To: 'Mantas Mikulenas'; yocto@yoctoproject.org
Subject: Re: [yocto] [systemd-devel] How to automount

> From: Mantas Mikulenas [mailto:grawity@gmail.com]
>
> > I don't think there's any way to have something auto-unmount
>
> There certainly is - udev has been unmounting unplugged
> drives for many years. It's done by default.

If creating a udev mount rule automatically does the unmount, then the
simplest thing for me would probably be to do that, and have my
application do a sync after each user-initiated operation. That way, the
drive would remain mounted after the operation, so I could still poke
around on it while debugging, yet there would be no corruption when it's
removed. Thanks for the tip.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com

--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [systemd-devel] How to automount

[Daniel.]

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

I thought that /etc/udev/scripts/mount.sh was tied to sysvinit

2015-09-22 15:33 GMT-03:00 Fred Ollinger <Fred.Ollinger@seescan.com>:

> This is in the package: udev-extraconf
>
> On your system look here:
>
> /etc/udev/rules.d/automount.rules
>
> In this file, you'll find the following rules.
>
> The second one auto unmounts.
>
> SUBSYSTEM=="block", ACTION=="add"    RUN+="/etc/udev/scripts/mount.sh"
>
> SUBSYSTEM=="block", ACTION=="remove" RUN+="/etc/udev/scripts/mount.sh"
>
> SUBSYSTEM=="block", ACTION=="change",
> ENV{DISK_MEDIA_CHANGE}=="1" RUN+="/etc/udev/scripts/mount.sh"
>
> ________________________________________
> From: yocto-bounces@yoctoproject.org <yocto-bounces@yoctoproject.org> on
> behalf of Paul D. DeRocco <pderocco@ix.netcom.com>
> Sent: Tuesday, September 22, 2015 10:45 AM
> To: 'Mantas Mikulenas'; yocto@yoctoproject.org
> Subject: Re: [yocto] [systemd-devel] How to automount
>
> > From: Mantas Mikulenas [mailto:grawity@gmail.com]
> >
> > > I don't think there's any way to have something auto-unmount
> >
> > There certainly is - udev has been unmounting unplugged
> > drives for many years. It's done by default.
>
> If creating a udev mount rule automatically does the unmount, then the
> simplest thing for me would probably be to do that, and have my
> application do a sync after each user-initiated operation. That way, the
> drive would remain mounted after the operation, so I could still poke
> around on it while debugging, yet there would be no corruption when it's
> removed. Thanks for the tip.
>
> --
>
> Ciao,               Paul D. DeRocco
> Paul                mailto:pderocco@ix.netcom.com
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
*"Do or do not. There is no try"*
  *Yoda Master*

[-- Attachment #2: Type: text/html, Size: 3379 bytes --]

Re: [systemd-devel] How to automount

[Paul D. DeRocco]

> From: Fred Ollinger [mailto:Fred.Ollinger@seescan.com] 
> 
> This is in the package: udev-extraconf
> 
> On your system look here:
> 
> /etc/udev/rules.d/automount.rules
> 
> In this file, you'll find the following rules.
> 
> The second one auto unmounts.
> 
> SUBSYSTEM=="block", ACTION=="add"    RUN+="/etc/udev/scripts/mount.sh"
> 
> SUBSYSTEM=="block", ACTION=="remove" RUN+="/etc/udev/scripts/mount.sh"
> 
> SUBSYSTEM=="block", ACTION=="change", 
> ENV{DISK_MEDIA_CHANGE}=="1" RUN+="/etc/udev/scripts/mount.sh"

Well, that started me down a long path. First of all, none of these things
existed because my Yocto build didn't include udev-extraconf. The version
I did two years ago did (although I didn't see it mentioned in my own
metadata), which is why it worked. So I added it back, rebuilt it, and
then tried plugging in a USB flash drive.

The drive appeared as /dev/sdb and /dev/sdb1 (it has a partition table),
The syslog showed the mount.sh script message "Auto-mount of
[/run/media/sdb1] successful", /run/media/sdb1 exists as a directory, but
nothing is mounted there. The next syslog message from FAT-fs said "Volume
was not properly unmounted. Some data may be corrupt. Please run fsck."
When I did that, all I found was that the dirty bit was set, so I
speculated that that caused the mount to somehow be undone.

So I cleaned the dirty bit, synced the file system, unplugged the drive
and plugged it in again. This time the syslog showed the successful mount
message, but no complaint about the drive. Yet it still wasn't mounted.

I can manually mount it, and see its contents. If I then yank the drive,
the mount.sh script doesn't unmount it. I even tweaked the script to log
any attempt to unmount, and it didn't even try.

Whenever I fix the dirty bit, disconnecting and reconnecting logs the
successful mount message, doesn't complain about the dirty bit, but
doesn't mount. Disconnecting again gives me a FAT-fs error "unable to read
boot sector to mark fs as dirty". Connecting again gives me the successful
mount message, and complains about the dirty bit.

Something must be missing here.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com

Re: [systemd-devel] How to automount

[Fred Ollinger]

You can see what udev thinks it will do for a given drive by using:

 $ udevadm test /sys/block/sdb1

Given that your drive is in /sys/block/sdb1 (could be sda1, etc).

As for the dirty bit, we had to clear it ourselves.

Frederick

________________________________________
From: Paul D. DeRocco <pderocco@ix.netcom.com>
Sent: Tuesday, September 22, 2015 4:42 PM
To: Fred Ollinger; 'Mantas Mikulenas'; yocto@yoctoproject.org
Subject: RE: [yocto] [systemd-devel] How to automount

> From: Fred Ollinger [mailto:Fred.Ollinger@seescan.com]
>
> This is in the package: udev-extraconf
>
> On your system look here:
>
> /etc/udev/rules.d/automount.rules
>
> In this file, you'll find the following rules.
>
> The second one auto unmounts.
>
> SUBSYSTEM=="block", ACTION=="add"    RUN+="/etc/udev/scripts/mount.sh"
>
> SUBSYSTEM=="block", ACTION=="remove" RUN+="/etc/udev/scripts/mount.sh"
>
> SUBSYSTEM=="block", ACTION=="change",
> ENV{DISK_MEDIA_CHANGE}=="1" RUN+="/etc/udev/scripts/mount.sh"

Well, that started me down a long path. First of all, none of these things
existed because my Yocto build didn't include udev-extraconf. The version
I did two years ago did (although I didn't see it mentioned in my own
metadata), which is why it worked. So I added it back, rebuilt it, and
then tried plugging in a USB flash drive.

The drive appeared as /dev/sdb and /dev/sdb1 (it has a partition table),
The syslog showed the mount.sh script message "Auto-mount of
[/run/media/sdb1] successful", /run/media/sdb1 exists as a directory, but
nothing is mounted there. The next syslog message from FAT-fs said "Volume
was not properly unmounted. Some data may be corrupt. Please run fsck."
When I did that, all I found was that the dirty bit was set, so I
speculated that that caused the mount to somehow be undone.

So I cleaned the dirty bit, synced the file system, unplugged the drive
and plugged it in again. This time the syslog showed the successful mount
message, but no complaint about the drive. Yet it still wasn't mounted.

I can manually mount it, and see its contents. If I then yank the drive,
the mount.sh script doesn't unmount it. I even tweaked the script to log
any attempt to unmount, and it didn't even try.

Whenever I fix the dirty bit, disconnecting and reconnecting logs the
successful mount message, doesn't complain about the dirty bit, but
doesn't mount. Disconnecting again gives me a FAT-fs error "unable to read
boot sector to mark fs as dirty". Connecting again gives me the successful
mount message, and complains about the dirty bit.

Something must be missing here.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com

Re: [systemd-devel] How to automount

[Paul D. DeRocco]

> From: Fred Ollinger [mailto:Fred.Ollinger@seescan.com] 
> 
> You can see what udev thinks it will do for a given drive by using:
> 
>  $ udevadm test /sys/block/sdb1
> 
> Given that your drive is in /sys/block/sdb1 (could be sda1, etc).

It's definitely running mount.sh, and the mount succeeds. Yet something is
subsequently unmounting it, and it's not the "remove" code at the end of
mount.sh. If I rename /bin/umount to something else, then the mount
remains intact. Do you or anyone have any ideas on how I might figure out
what is invoking "umount" right after the drive is mounted?

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com

Re: [systemd-devel] How to automount

[Daniel.]

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

If there is any process using the mount point the umount may fail. If you
have a bash running in a folder from the mounted filesystem is the
sufficient to umount fail.

You can use the fuser -m MOUTPOINT to check this. Adding -k would kill all
process using that mount point.

"udevadm monitor" should show you udev events interactive.

Cheers,
-dhs
Em 22/09/2015 20:49, "Fred Ollinger" <Fred.Ollinger@seescan.com> escreveu:

> You can see what udev thinks it will do for a given drive by using:
>
>  $ udevadm test /sys/block/sdb1
>
> Given that your drive is in /sys/block/sdb1 (could be sda1, etc).
>
> As for the dirty bit, we had to clear it ourselves.
>
> Frederick
>
> ________________________________________
> From: Paul D. DeRocco <pderocco@ix.netcom.com>
> Sent: Tuesday, September 22, 2015 4:42 PM
> To: Fred Ollinger; 'Mantas Mikulenas'; yocto@yoctoproject.org
> Subject: RE: [yocto] [systemd-devel] How to automount
>
> > From: Fred Ollinger [mailto:Fred.Ollinger@seescan.com]
> >
> > This is in the package: udev-extraconf
> >
> > On your system look here:
> >
> > /etc/udev/rules.d/automount.rules
> >
> > In this file, you'll find the following rules.
> >
> > The second one auto unmounts.
> >
> > SUBSYSTEM=="block", ACTION=="add"    RUN+="/etc/udev/scripts/mount.sh"
> >
> > SUBSYSTEM=="block", ACTION=="remove" RUN+="/etc/udev/scripts/mount.sh"
> >
> > SUBSYSTEM=="block", ACTION=="change",
> > ENV{DISK_MEDIA_CHANGE}=="1" RUN+="/etc/udev/scripts/mount.sh"
>
> Well, that started me down a long path. First of all, none of these things
> existed because my Yocto build didn't include udev-extraconf. The version
> I did two years ago did (although I didn't see it mentioned in my own
> metadata), which is why it worked. So I added it back, rebuilt it, and
> then tried plugging in a USB flash drive.
>
> The drive appeared as /dev/sdb and /dev/sdb1 (it has a partition table),
> The syslog showed the mount.sh script message "Auto-mount of
> [/run/media/sdb1] successful", /run/media/sdb1 exists as a directory, but
> nothing is mounted there. The next syslog message from FAT-fs said "Volume
> was not properly unmounted. Some data may be corrupt. Please run fsck."
> When I did that, all I found was that the dirty bit was set, so I
> speculated that that caused the mount to somehow be undone.
>
> So I cleaned the dirty bit, synced the file system, unplugged the drive
> and plugged it in again. This time the syslog showed the successful mount
> message, but no complaint about the drive. Yet it still wasn't mounted.
>
> I can manually mount it, and see its contents. If I then yank the drive,
> the mount.sh script doesn't unmount it. I even tweaked the script to log
> any attempt to unmount, and it didn't even try.
>
> Whenever I fix the dirty bit, disconnecting and reconnecting logs the
> successful mount message, doesn't complain about the dirty bit, but
> doesn't mount. Disconnecting again gives me a FAT-fs error "unable to read
> boot sector to mark fs as dirty". Connecting again gives me the successful
> mount message, and complains about the dirty bit.
>
> Something must be missing here.
>
> --
>
> Ciao,               Paul D. DeRocco
> Paul                mailto:pderocco@ix.netcom.com
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

[-- Attachment #2: Type: text/html, Size: 4503 bytes --]

Re: [systemd-devel] How to automount

[Paul D. DeRocco]

> From: Daniel. [mailto:danielhilst@gmail.com] 
> 
> If there is any process using the mount point the umount may 
> fail. If you have a bash running in a folder from the mounted 
> filesystem is the sufficient to umount fail.
> 
> You can use the fuser -m MOUTPOINT to check this. Adding -k 
> would kill all process using that mount point.

Now I'm totally confused. Renaming /bin/umount to something else, and then
plugging in the drive, is no longer leaving the successful mount intact. I
saw it do this twice, but it's not doing it any more. I even tried
replacing /bin/umount with a script that ran fuser with the results going
to a file, and it's never being invoked. But the missing /bin/umount does
indeed screw things up, giving me a slew of FAT-fs read errors. It also
leaves /run/media/sdb1 as an empty directory that can't be deleted
("Device or resource busy") even though fuser doesn't show any processes
using it.

This makes no sense. How can this auto-mounting not work? Is it known to
be brittle, or is it believed to be reliable? All I did was include
udev-extraconf in my build.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com

Re: [systemd-devel] How to automount

[Daniel.]

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

Okay, first of all have sure that there is no bash sitting ou your mount
point. Check if the file /etc/udev/rules.d/automount.rules is present. Then
try "udevadm monitor", plug and displug the device and see if you got the
"add" em "remove" events, this is what sould invoke mount.sh. Also check
/etc/udev/mount.blacklist, have sure that your device is not present in
this file.

Next, try to add this "exec > /home/root/mount.sh.log 2>&1" to beginning of
/etc/udev/scripts/mount.sh and try unplug/plug again. This will redirect
all output and errors to /home/root/mount.sh.log file. Check its contents,
there should be an error message or something alike.

I've alredy had problems with FAT filesystems being mounted as ready-only
after some time. This could be circumvented by adding "errors=continue" to
mount options but keep in mind that this is not safe. I would suggest you
to use a native filesystem, like ext4 which is more realible. You can
access it from windows (if this is the reason why you use FAT) with any
sftp client as long as you have openssh in your image features.

Regards,
- dhs

2015-09-22 22:20 GMT-03:00 Paul D. DeRocco <pderocco@ix.netcom.com>:

> > From: Daniel. [mailto:danielhilst@gmail.com]
> >
> > If there is any process using the mount point the umount may
> > fail. If you have a bash running in a folder from the mounted
> > filesystem is the sufficient to umount fail.
> >
> > You can use the fuser -m MOUTPOINT to check this. Adding -k
> > would kill all process using that mount point.
>
> Now I'm totally confused. Renaming /bin/umount to something else, and then
> plugging in the drive, is no longer leaving the successful mount intact. I
> saw it do this twice, but it's not doing it any more. I even tried
> replacing /bin/umount with a script that ran fuser with the results going
> to a file, and it's never being invoked. But the missing /bin/umount does
> indeed screw things up, giving me a slew of FAT-fs read errors. It also
> leaves /run/media/sdb1 as an empty directory that can't be deleted
> ("Device or resource busy") even though fuser doesn't show any processes
> using it.
>
> This makes no sense. How can this auto-mounting not work? Is it known to
> be brittle, or is it believed to be reliable? All I did was include
> udev-extraconf in my build.
>
> --
>
> Ciao,               Paul D. DeRocco
> Paul                mailto:pderocco@ix.netcom.com
>
>


-- 
*"Do or do not. There is no try"*
  *Yoda Master*

[-- Attachment #2: Type: text/html, Size: 3370 bytes --]

Re: [systemd-devel] How to automount

[Mike Looijmans]

On 22-09-15 20:33, Fred Ollinger wrote:
...
> SUBSYSTEM=="block", ACTION=="remove" RUN+="/etc/udev/scripts/mount.sh"

This only serves to remove a mounted directory after "yanking" the device. It 
doesn't really do anything useful though, you'll still get corrupted 
filesystems, because Linux is way too lazy in writing out dirty data.

Proper solution would be to have the system mount a removable device as 
read-only, and promote it to r/w once someone tries to write to it. And then 
after a timeout, it should go back to readonly.

Supposedly, "autofs" can accomplish this, but I've never met anyone who got 
that to actually work.



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

Re: [systemd-devel] How to automount

[Paul D. DeRocco]

> From: Mike Looijmans
> 
> This only serves to remove a mounted directory after 
> "yanking" the device. It 
> doesn't really do anything useful though, you'll still get corrupted 
> filesystems, because Linux is way too lazy in writing out dirty data.
> 
> Proper solution would be to have the system mount a removable 
> device as 
> read-only, and promote it to r/w once someone tries to write 
> to it. And then 
> after a timeout, it should go back to readonly.
> 
> Supposedly, "autofs" can accomplish this, but I've never met 
> anyone who got 
> that to actually work.

In my system, the removable drive is used only for backing up or restoring
various data files in response to user commands. If I do a sync after each
such command, shouldn't that be enough to guarantee the file system
doesn't get corrupted when the drive is removed? Will it also ensure the
dirty flag is clear, or does that get set anyway?

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com

Re: [systemd-devel] How to automount

[Daniel.]

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

I think that sync just flushes data to disk and umount clears the dirty
bit. There is no sync.vfat that I know.
Em 23/09/2015 05:31, "Paul D. DeRocco" <pderocco@ix.netcom.com> escreveu:

> > From: Mike Looijmans
> >
> > This only serves to remove a mounted directory after
> > "yanking" the device. It
> > doesn't really do anything useful though, you'll still get corrupted
> > filesystems, because Linux is way too lazy in writing out dirty data.
> >
> > Proper solution would be to have the system mount a removable
> > device as
> > read-only, and promote it to r/w once someone tries to write
> > to it. And then
> > after a timeout, it should go back to readonly.
> >
> > Supposedly, "autofs" can accomplish this, but I've never met
> > anyone who got
> > that to actually work.
>
> In my system, the removable drive is used only for backing up or restoring
> various data files in response to user commands. If I do a sync after each
> such command, shouldn't that be enough to guarantee the file system
> doesn't get corrupted when the drive is removed? Will it also ensure the
> dirty flag is clear, or does that get set anyway?
>
> --
>
> Ciao,               Paul D. DeRocco
> Paul                mailto:pderocco@ix.netcom.com
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

[-- Attachment #2: Type: text/html, Size: 2023 bytes --]

Re: [systemd-devel] How to automount

[Paul D. DeRocco]

> From: Daniel. [mailto:danielhilst@gmail.com] 
> 
> I think that sync just flushes data to disk and umount clears 
> the dirty bit. There is no sync.vfat that I know.

That would seem to make auto-unmount (triggered by removal) an
intrinsically unworkable concept. Or is that only the case for FAT file
systems?

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com

Re: [systemd-devel] How to automount

[Daniel.]

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

I agree with you that is intrinsically unworkable, if there is no physical
media, how can it be umounted!? If anyone make this possible, maybe some
day, in that day, umounting will be obsolete.

Cheers,
- dhs

2015-09-23 15:31 GMT-03:00 Paul D. DeRocco <pderocco@ix.netcom.com>:

> > From: Daniel. [mailto:danielhilst@gmail.com]
> >
> > I think that sync just flushes data to disk and umount clears
> > the dirty bit. There is no sync.vfat that I know.
>
> That would seem to make auto-unmount (triggered by removal) an
> intrinsically unworkable concept. Or is that only the case for FAT file
> systems?
>
> --
>
> Ciao,               Paul D. DeRocco
> Paul                mailto:pderocco@ix.netcom.com
>
>


-- 
*"Do or do not. There is no try"*
  *Yoda Master*

[-- Attachment #2: Type: text/html, Size: 1471 bytes --]

Re: [systemd-devel] How to automount

[Mike Looijmans]

On 23-09-15 12:09, Daniel. wrote:
> I think that sync just flushes data to disk and umount clears the dirty bit.
> There is no sync.vfat that I know.
>
> Em 23/09/2015 05:31, "Paul D. DeRocco" <pderocco@ix.netcom.com
> <mailto:pderocco@ix.netcom.com>> escreveu:
>
>      > From: Mike Looijmans
>      >
>      > This only serves to remove a mounted directory after
>      > "yanking" the device. It
>      > doesn't really do anything useful though, you'll still get corrupted
>      > filesystems, because Linux is way too lazy in writing out dirty data.
>      >
>      > Proper solution would be to have the system mount a removable
>      > device as
>      > read-only, and promote it to r/w once someone tries to write
>      > to it. And then
>      > after a timeout, it should go back to readonly.
>      >
>      > Supposedly, "autofs" can accomplish this, but I've never met
>      > anyone who got
>      > that to actually work.
>
>     In my system, the removable drive is used only for backing up or restoring
>     various data files in response to user commands. If I do a sync after each
>     such command, shouldn't that be enough to guarantee the file system
>     doesn't get corrupted when the drive is removed? Will it also ensure the
>     dirty flag is clear, or does that get set anyway?

Nope, "sync" does not clear the flag. Only umount does that (the same for any 
filesystem, this is not fat specific). Actually, sync is no guarantee that 
it's actually safe to yank the stick, data could still reside in buffers 
somewhere. Only umount (sort of) guarantees that.

The only thing that would really work is to unmount the device.

You could try mounting it read-only by default, and remount it before (rw) and 
after (ro) writing to it. Since it's under your control, it's possible to 'get 
it right' here and always have clean media.



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail