Does XFS support the sync mount option?

Does XFS support the sync mount option?

[Ewan Chalmers]

I am interested to know whether XFS supports the sync mount option.

I am using XFS on an external USB disk and automounting using the
ubuntu/debian usbmount package
(http://packages.ubuntu.com/intrepid/usbmount). The disk is connected
to a headless server. I would like to be able to safely switch the
disk on/off on demand without first logging in to the box to
sync/unmount. I believe the sync option is essential to this use case.
Using usbmount, it appears to work correctly, but the output to syslog
makes me wonder.

The default configuration for usbmount includes

FILESYSTEMS="ext2 ext3"
MOUNTOPTIONS="sync,noexec,nodev,noatime"

I have added xfs to the FILESYSTEMS list.

On switching off the disk, I see the following output in syslog

kernel: [1034259.923629] usb 1-2: USB disconnect, address 26
kernel: [1034259.936251] xfs_force_shutdown(sdb1,0x1) called from line
420 of file /build/buildd/linux-2.6.27/fs/xfs/xfs_rw.c.  Return
address = 0xe0a9ddb4
kernel: [1034259.936334] Filesystem "sdb1": I/O Error Detected.
Shutting down filesystem: sdb1
kernel: [1034259.936404] Please umount the filesystem, and rectify the
problem(s)
kernel: [1034259.949818] Filesystem "sdb1": xfs_log_force: error 5 returned.
kernel: [1034259.949851] Filesystem "sdb1": xfs_log_force: error 5 returned.
kernel: [1034259.949890] xfs_force_shutdown(sdb1,0x1) called from line
420 of file /build/buildd/linux-2.6.27/fs/xfs/xfs_rw.c.  Return
address = 0xe0a9ddb4
kernel: [1034259.968157] Filesystem "sdb1": xfs_log_force: error 5 returned.
usbmount[16307]: executing command: umount -l /media/usb0
kernel: [1034260.050924] Filesystem "sdb1": xfs_log_force: error 5 returned.
kernel: [1034260.057086] Filesystem "sdb1": xfs_log_force: error 5 returned.
kernel: [1034260.061208] xfs_force_shutdown(sdb1,0x1) called from line
420 of file /build/buildd/linux-2.6.27/fs/xfs/xfs_rw.c.  Return
address = 0xe0a9ddb4
kernel: [1034260.069650] Filesystem "sdb1": xfs_log_force: error 5 returned.
kernel: [1034260.073675] Filesystem "sdb1": xfs_log_force: error 5 returned.
kernel: [1034260.077672] xfs_force_shutdown(sdb1,0x1) called from line
420 of file /build/buildd/linux-2.6.27/fs/xfs/xfs_rw.c.  Return
address = 0xe0a9ddb4
usbmount[16307]: executing command: run-parts /etc/usbmount/umount.d
kernel: [1034260.084706] Filesystem "sdb1": xfs_log_force: error 5 returned.
kernel: [1034260.084735] Filesystem "sdb1": xfs_log_force: error 5 returned.
kernel: [1034260.084820] Filesystem "sdb1": xfs_log_force: error 5 returned.
kernel: [1034260.084864] Filesystem "sdb1": xfs_log_force: error 5 returned.
kernel: [1034260.084891] Filesystem "sdb1": xfs_log_force: error 5 returned.

But the disk remounts cleanly when it is switched back on.

kernel: [1034394.920087] usb 1-2: new high speed USB device using
ehci_hcd and address 27
kernel: [1034395.064826] usb 1-2: configuration #1 chosen from 1 choice
kernel: [1034395.078845] scsi25 : SCSI emulation for USB Mass Storage devices
kernel: [1034395.085992] usb-storage: device found at 27
kernel: [1034395.086033] usb-storage: waiting for device to settle
before scanning
kernel: [1034400.084595] usb-storage: device scan complete
kernel: [1034400.087474] scsi 25:0:0:0: Direct-Access     WDC WD10
EADS-00L5B1      0041 PQ: 0 ANSI: 0
kernel: [1034400.091636] sd 25:0:0:0: [sdb] 1953525168 512-byte
hardware sectors (1000205 MB)
kernel: [1034400.094271] sd 25:0:0:0: [sdb] Write Protect is off
kernel: [1034400.094309] sd 25:0:0:0: [sdb] Mode Sense: 03 00 00 00
kernel: [1034400.094328] sd 25:0:0:0: [sdb] Assuming drive cache: write through
kernel: [1034400.104985] sd 25:0:0:0: [sdb] 1953525168 512-byte
hardware sectors (1000205 MB)
kernel: [1034400.113058] sd 25:0:0:0: [sdb] Write Protect is off
kernel: [1034400.113094] sd 25:0:0:0: [sdb] Mode Sense: 03 00 00 00
kernel: [1034400.113114] sd 25:0:0:0: [sdb] Assuming drive cache: write through
kernel: [1034400.120193]  sdb: sdb1
kernel: [1034400.137434] sd 25:0:0:0: [sdb] Attached SCSI disk
kernel: [1034400.137980] sd 25:0:0:0: Attached scsi generic sg1 type 0
usbmount[16483]: executing command: mount -txfs
-osync,noexec,nodev,noatime /dev/sdb1 /media/usb0
kernel: [1034401.228110] XFS mounting filesystem sdb1
kernel: [1034401.710070] Ending clean XFS mount for filesystem: sdb1
usbmount[16483]: executing command: run-parts /etc/usbmount/mount.d

I would be interested to know whether it is reasonable to use XFS in
the way I have outlined.

Thanks,
Ewan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Does XFS support the sync mount option?

[Dave Chinner]

On Thu, Feb 05, 2009 at 02:43:29PM +0000, Ewan Chalmers wrote:
> I am interested to know whether XFS supports the sync mount option.

Yes.

> I am using XFS on an external USB disk and automounting using the
> ubuntu/debian usbmount package
> (http://packages.ubuntu.com/intrepid/usbmount). The disk is connected
> to a headless server. I would like to be able to safely switch the
> disk on/off on demand without first logging in to the box to
> sync/unmount. I believe the sync option is essential to this use case.
> Using usbmount, it appears to work correctly, but the output to syslog
> makes me wonder.

You've pulled the plug on the block device, and you wonder why the
filesystem detects an IO error and shutѕ down? XFS is designed to protect
itself when something goes wrong with the underlying device.
Every time you switch off the drive you'll get these errors.

And "sync" only works if you turn drive write caches off or have
barriers enabled. There are many people out there that  have systems
that are suseptible to fatal filesystem corruption that could be
triggered by doing this (because critical metadata is lost from
the volatile write cache on the drive when you power it off).

> The default configuration for usbmount includes
> 
> FILESYSTEMS="ext2 ext3"
> MOUNTOPTIONS="sync,noexec,nodev,noatime"

Oh, that might explain why kerneloops records so many crashes in
ext2/3 from people pulling the plug on USB drives...

> I have added xfs to the FILESYSTEMS list.

Please don't. I don't want to have to deal with all the shutdowns
and corrupted filesystem reports that this will result in.

> On switching off the disk, I see the following output in syslog
>
> kernel: [1034259.923629] usb 1-2: USB disconnect, address 26
> kernel: [1034259.936251] xfs_force_shutdown(sdb1,0x1) called from line
> 420 of file /build/buildd/linux-2.6.27/fs/xfs/xfs_rw.c.  Return
> address = 0xe0a9ddb4
> kernel: [1034259.936334] Filesystem "sdb1": I/O Error Detected.
> Shutting down filesystem: sdb1
....
> But the disk remounts cleanly when it is switched back on.

That doesn't mean it hasn't been corrupted. Only an offline
check/repair will tell you that.

> I would be interested to know whether it is reasonable to use XFS in
> the way I have outlined.

No, it's not really a reasonable way to use any filesystem.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Does XFS support the sync mount option?

[Michael Monnerie]

[-- Attachment #1.1: Type: text/plain, Size: 1010 bytes --]

On Samstag 07 Februar 2009 Dave Chinner wrote:
>>  I would be interested to know whether it is reasonable to use XFS in
> > the way I have outlined.
> No, it's not really a reasonable way to use any filesystem.

But what would be? Of course people will pull out an USB stick/drive 
wihtout unmounting, and it should be save anyway if
1) disk write cache=off and/or barrier enabled
2) they wait until the light of the USB stick/drive stops blinking after 
copying the file onto it. That usually means it's finished.

There will be logs about problems, because it's not a nice way to 
shutdown the filesystem, but it should be safe I'd say.

mfg zmi
-- 
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4


[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Does XFS support the sync mount option?

[Ewan Chalmers]

Thanks for your detailed reply.

> And "sync" only works if you turn drive write caches off or have
> barriers enabled. There are many people out there that  have systems
> that are suseptible to fatal filesystem corruption that could be
> triggered by doing this (because critical metadata is lost from
> the volatile write cache on the drive when you power it off).

According to the FAQ, barriers are enabled by default since 2.6.17. I
have 2.9.8, so I guess barriers are enabled. I have checked and dmesg
contains no errors relating to barriers.

Also according the FAQ... "With a single hard disk and barriers turned
on (on=default), the drive write cache is flushed before an after a
barrier is issued. A powerfail "only" loses data in the cache but no
essential ordering is violated, and corruption will not occur."

So it sounds like pulling the plug on the disk should not cause
corruption in this case (sync mount and barriers default enabled). Or
am I just plain wrong?

(BTW, I've done an xfs_repair which reported no errors.)

Thanks,
Ewan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Does XFS support the sync mount option?

[Eric Sandeen]

Ewan Chalmers wrote:
> Thanks for your detailed reply.
> 
>> And "sync" only works if you turn drive write caches off or have
>> barriers enabled. There are many people out there that  have systems
>> that are suseptible to fatal filesystem corruption that could be
>> triggered by doing this (because critical metadata is lost from
>> the volatile write cache on the drive when you power it off).
> 
> According to the FAQ, barriers are enabled by default since 2.6.17.

That's kernel version

> I
> have 2.9.8, 

that's xfsprogs version.

> so I guess barriers are enabled. I have checked and dmesg
> contains no errors relating to barriers.
> 
> Also according the FAQ... "With a single hard disk and barriers turned
> on (on=default), the drive write cache is flushed before an after a
> barrier is issued. A powerfail "only" loses data in the cache but no
> essential ordering is violated, and corruption will not occur."
> 
> So it sounds like pulling the plug on the disk should not cause
> corruption in this case (sync mount and barriers default enabled). Or
> am I just plain wrong?

It should not cause metadata corruption

> (BTW, I've done an xfs_repair which reported no errors.)

... which is what repair will check for.

-Eric

> Thanks,
> Ewan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs