mirrors/scst
1
0
Fork 0
mirror of https://github.com/SCST-project/scst.git synced 2026-08-21 06:36:27 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix broken link from scst/README to XFS FAQ reported by Sebastian Herbszt <herbszt@gmx.de>

Browse Source 
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5222 d57e44dd-8a1f-0410-8b47-8ef2f437770f
This commit is contained in:
Vladislav Bolkhovitin
2014-01-22 03:03:04 +00:00
parent 85ea152e0c
commit 0611548744
2 changed files with 14 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files
scst/README
+7 -7
View File
@@ -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.
scst/README_in-tree
+7 -7
View File
@@ -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.