From 06115487444cf27ad55e65ec7727163d9b0292f3 Mon Sep 17 00:00:00 2001 From: Vladislav Bolkhovitin Date: Wed, 22 Jan 2014 03:03:04 +0000 Subject: [PATCH] Fix broken link from scst/README to XFS FAQ reported by Sebastian Herbszt git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5222 d57e44dd-8a1f-0410-8b47-8ef2f437770f --- scst/README | 14 +++++++------- scst/README_in-tree | 14 +++++++------- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/scst/README b/scst/README index 150965213..399aaea29 100644 --- a/scst/README +++ b/scst/README @@ -1484,13 +1484,13 @@ enable barriers on your backend file system on the target (for direct /dev/sdX devices this is, indeed, impossible), or need a good UPS to protect yourself from not committed data loss. Some info about barriers from the XFS point of view could be found at -http://oss.sgi.com/projects/xfs/faq.html#wcache. On Linux initiators for -Ext3 and ReiserFS file systems the barrier protection could be turned on -using "barrier=1" and "barrier=flush" mount options correspondingly. You -can check if the barriers turn on or off by looking in /proc/mounts. -Windows and, AFAIK, other UNIX'es don't need any special explicit -options and do necessary barrier actions on write-back caching devices -by default. +http://xfs.org/index.php/XFS_FAQ#Write_barrier_support. On Linux +initiators for Ext3 and ReiserFS file systems the barrier protection +could be turned on using "barrier=1" and "barrier=flush" mount options +correspondingly. You can check if the barriers turn on or off by looking +in /proc/mounts. Windows and, AFAIK, other UNIX'es don't need any +special explicit options and do necessary barrier actions on write-back +caching devices by default. To limit this data loss with write back caching you can use files in /proc/sys/vm to limit amount of unflushed data in the system cache. diff --git a/scst/README_in-tree b/scst/README_in-tree index abd4f88f4..055802881 100644 --- a/scst/README_in-tree +++ b/scst/README_in-tree @@ -1064,13 +1064,13 @@ enable barriers on your backend file system on the target (for direct /dev/sdX devices this is, indeed, impossible), or need a good UPS to protect yourself from not committed data loss. Some info about barriers from the XFS point of view could be found at -http://oss.sgi.com/projects/xfs/faq.html#wcache. On Linux initiators for -Ext3 and ReiserFS file systems the barrier protection could be turned on -using "barrier=1" and "barrier=flush" mount options correspondingly. You -can check if the barriers turn on or off by looking in /proc/mounts. -Windows and, AFAIK, other UNIX'es don't need any special explicit -options and do necessary barrier actions on write-back caching devices -by default. +http://xfs.org/index.php/XFS_FAQ#Write_barrier_support. On Linux +initiators for Ext3 and ReiserFS file systems the barrier protection +could be turned on using "barrier=1" and "barrier=flush" mount options +correspondingly. You can check if the barriers turn on or off by looking +in /proc/mounts. Windows and, AFAIK, other UNIX'es don't need any +special explicit options and do necessary barrier actions on write-back +caching devices by default. To limit this data loss with write back caching you can use files in /proc/sys/vm to limit amount of unflushed data in the system cache.