Re: usb disk dirty after every reboot
On Thursday, 20 October 2016 20:55:47 CEST Lampshade wrote: > What if somebody remounts > from normal options > (metadata: sync, data: async) > to fully synced > (metadata: sync, data: sync) > > Example: > # mount | grep home > /dev/sd1h on /home type ffs (local, noatime, nodev, nosuid) > # /sbin/mount -u -o sync,rw,nodev,nosuid,noatime /home > # mount | grep home > /dev/sd1h on /home type ffs (local, noatime, nodev, nosuid, synchronous) > > Should this flush cache for this particular filesystem? I don't think so because sync mounts make no guarantee with respect to the disk's write cache. But this is not a strong opinion. Cheers, Stefan
Re: usb disk dirty after every reboot
>I found a few cases, where we should send a cache flush but don't. >Unfortunately, none of these cases explain the problem seen by >Jan and Darren. >The cases I have found are: >* When a R/W mount is updated to R/O. I will send patches for this in a >separate mail. >* When a R/W mount is unmounted but there is still another partition from the >same disk mounted. >* When sync(2) is called. Though I am not 100% sure if we really want > to do a cache flush for every sync. Thoughts? What if somebody remounts from normal options (metadata: sync, data: async) to fully synced (metadata: sync, data: sync) Example: # mount | grep home /dev/sd1h on /home type ffs (local, noatime, nodev, nosuid) # /sbin/mount -u -o sync,rw,nodev,nosuid,noatime /home # mount | grep home /dev/sd1h on /home type ffs (local, noatime, nodev, nosuid, synchronous) Should this flush cache for this particular filesystem?
Re: usb disk dirty after every reboot
On Oct 16 10:14:14, s...@sfritsch.de wrote: > [moving to tech@] > > On Tuesday, 20 September 2016 08:03:32 CEST Stefan Fritsch wrote: > > On Tue, 20 Sep 2016, Darren Tucker wrote: > > > On Tue, Sep 20, 2016 at 1:43 AM, Jan Stary wrote: > > > > This is current/i386 on an ALIX.1E (demsg below). > > > > I have an USB disk connected for /backup. > > > > > > > > Upon every reboot, the filesystem on that disk is dirty: > > > > WARNING: R/W mount of /backup denied. Filesystem is not clean - run > > > > fsck Since then, I have used three different disks and USB enclosures, each working flawlessly anywhere else. The problem is still there, so it's most probably not the disk. > > > I saw something similar on an APU where the root disk was on > > > (USB-attached) sdcard: > > > http://marc.info/?l=openbsd-misc&m=144237305322074&w=2 > > > > > > It seems to be a race. There used to be a 4sec pause in the kernel > > > that was removed: > > > > > > """ > > > Remove 4 second delay on reboot/shutdown that was added 8 years > > > ago to "workaround MP timeout/splhigh/scsi race at reboot time". > > > """ > > I think before we re-add some arbitrary delays, we should check if we are > > actually sending an explicit cache flush command to the disk controllers. > > I have some code somewhere that does this for umount and mount -ur. I will > > look for it and send it to tech@, but probably not today. For now, I just put 'umount /backup' in my rc.shutdown and that makes it umount cleanly. > I found a few cases, where we should send a cache flush but don't. > Unfortunately, none of these cases explain the problem seen by Jan and Darren. > > The cases I have found are: > > * When a R/W mount is updated to R/O. I will send patches for this in a > separate mail. Not this case. > * When a R/W mount is unmounted but there is still another partition from the > same disk mounted. Not this case. > For the usb disk issue, some more debugging is necessary. How can I help debug this? Jan Controller /dev/usb0: addr 1: high speed, self powered, config 1, EHCI root hub(0x), AMD(0x1022), rev 1.00 port 1 powered port 2 powered port 3 addr 2: high speed, self powered, config 1, Mass Storage Device(0x2506), Prolific Technology Inc.(0x067b), rev 1.00, iSerialNumber port 4 powered Controller /dev/usb1: addr 1: full speed, self powered, config 1, OHCI root hub(0x), AMD(0x1022), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered
Re: usb disk dirty after every reboot
> * When sync(2) is called. Though I am not 100% sure if we really want to do a > cache flush for every sync. Thoughts? We definately cannot it there. The system call is asyncronous, and makes no gaurantees. Furthermore note that any user can call sync(2), so unknown performance would come under control of any user. Note the manual page declares this is a BUG, but it actually isn't. This was by design. Yes, it is a pretty old unix wart BUGS sync() may return before the buffers are completely flushed.
Re: usb disk dirty after every reboot
[moving to tech@] On Tuesday, 20 September 2016 08:03:32 CEST Stefan Fritsch wrote: > On Tue, 20 Sep 2016, Darren Tucker wrote: > > On Tue, Sep 20, 2016 at 1:43 AM, Jan Stary wrote: > > > This is current/i386 on an ALIX.1E (demsg below). > > > I have an USB disk connected for /backup. > > > > > > Upon every reboot, the filesystem on that disk is dirty: > > > WARNING: R/W mount of /backup denied. Filesystem is not clean - run > > > fsck > > > > I saw something similar on an APU where the root disk was on > > (USB-attached) sdcard: > > http://marc.info/?l=openbsd-misc&m=144237305322074&w=2 > > > > It seems to be a race. There used to be a 4sec pause in the kernel > > that was removed: > > > > """ > > Remove 4 second delay on reboot/shutdown that was added 8 years > > ago to "workaround MP timeout/splhigh/scsi race at reboot time". > > """ > > I think before we re-add some arbitrary delays, we should check if we are > actually sending an explicit cache flush command to the disk controllers. > I have some code somewhere that does this for umount and mount -ur. I will > look for it and send it to tech@, but probably not today. I found a few cases, where we should send a cache flush but don't. Unfortunately, none of these cases explain the problem seen by Jan and Darren. The cases I have found are: * When a R/W mount is updated to R/O. I will send patches for this in a separate mail. * When a R/W mount is unmounted but there is still another partition from the same disk mounted. * When sync(2) is called. Though I am not 100% sure if we really want to do a cache flush for every sync. Thoughts? For the usb disk issue, some more debugging is necessary. Cheers, Stefan
