summaryrefslogtreecommitdiffstats
path: root/docs-xml/manpages-3/vfs_crossrename.8.xml
blob: ba7c7c8419731896b7003a0913e88ea5b70c7bdc (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE refentry PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
<refentry id="vfs_crossrename.8">

<refmeta>
	<refentrytitle>vfs_crossrename</refentrytitle>
	<manvolnum>8</manvolnum>
	<refmiscinfo class="source">Samba</refmiscinfo>
	<refmiscinfo class="manual">System Administration tools</refmiscinfo>
	<refmiscinfo class="version">3.6</refmiscinfo>
</refmeta>


<refnamediv>
	<refname>vfs_crossrename</refname>
	<refpurpose>server side rename files across filesystem boundaries</refpurpose>
</refnamediv>

<refsynopsisdiv>
	<cmdsynopsis>
		<command>vfs objects = crossrename</command>
	</cmdsynopsis>
</refsynopsisdiv>

<refsect1>
	<title>DESCRIPTION</title>

	<para>This VFS module is part of the
	<citerefentry><refentrytitle>samba</refentrytitle>
	<manvolnum>7</manvolnum></citerefentry> suite.</para>

	<para>The <command>vfs_crossrename</command> VFS module allows
	server side rename operations even if source and target are on
	different physical devices. A "move" in Explorer is usually a
	rename operation if it is inside of a single share or device.
	Usually such a rename operation returns
	NT_STATUS_NOT_SAME_DEVICE and the client has to move the file by
	manual copy and delete operations. If the rename by copy is done by the
	server this can be much more efficient. vfs_crossrename tries to do
	this server-side cross-device rename operation. There are however
	limitations that this module currently does not solve:

	<variablelist>
		<varlistentry>
		the ACLs of files are not preserved
		</varlistentry>
		<varlistentry>
		meta data in EAs are not preserved
		</varlistentry>
		<varlistentry>
		renames of whole subdirectories cannot be done recursively,
		in that case we still return STATUS_NOT_SAME_DEVICE and
		let the client decide what to do
		</varlistentry>
		<varlistentry>
		rename operations of huge files can cause hangs on the
		client because clients expect a rename operation to
		return fast
		</varlistentry>
	</variablelist>
	</para>

	<para>This module is stackable.</para>

</refsect1>


<refsect1>
	<title>OPTIONS</title>

	<variablelist>

		<varlistentry>
		<term>crossrename:sizelimit = BYTES</term>
		<listitem>
		<para>server-side cross-device-renames are only done
		for files if the filesize is not larger than the defined
		size in MiB to prevent timeouts. The default sizelimit is
		20 (MiB)
		</para>
		</listitem>
		</varlistentry>
	</variablelist>
</refsect1>

<refsect1>
	<title>EXAMPLES</title>

	<para>To add server-side cross-device renames inside of a share
	for all files sized up to 50MB:</para>

<programlisting>
        <smbconfsection name="[testshare]"/>
	<smbconfoption name="path">/data/mounts</smbconfoption>
	<smbconfoption name="vfs objects">crossrename</smbconfoption>
	<smbconfoption name="crossrename:sizelimit">50</smbconfoption>
</programlisting>
</refsect1>

<refsect1>
	<title>VERSION</title>
	<para>This man page is correct for version 3.6.0 of the Samba suite.
	</para>
</refsect1>

<refsect1>
	<title>AUTHOR</title>

	<para>The original Samba software and related utilities
	were created by Andrew Tridgell. Samba is now developed
	by the Samba Team as an Open Source project similar
	to the way the Linux kernel is developed.</para>

</refsect1>

</refentry>
e work to be done whenever the event occurs. This work normally includes extracting data from the event context, storing them into internal variables, and printing results. </para> <section id="understanding-architecture-tools"> <title>Architecture</title> <remark> ** add diagram, describe architecture, enumerate common tools </remark> <remark> ** architecture diagram must be simpler, if at all included </remark> <remark> ** add design advantages? e.g. "building kmods on-the-fly allows safer execution of script etc etc" </remark> <indexterm> <primary>Understanding How SystemTap Works</primary> <secondary>architecture</secondary> </indexterm> <indexterm> <primary>architecture of SystemTap</primary> </indexterm> <indexterm> <primary>SystemTap architecture</primary> </indexterm> <para> A SystemTap session begins when you run a SystemTap script. This session occurs in the following fashion: </para> <procedure id="systemtapsession"> <title>SystemTap Session</title> <indexterm> <primary>Understanding How SystemTap Works</primary> <secondary>SystemTap sessions</secondary> </indexterm> <indexterm> <primary>SystemTap sessions</primary> </indexterm> <indexterm> <primary>sessions, SystemTap</primary> </indexterm> <step> <para> First, SystemTap checks the script against the existing tapset library (normally in <filename>/usr/share/systemtap/tapset/</filename> for any tapsets used. SystemTap will then substitute any located tapsets with their corresponding definitions in the tapset library. </para> </step> <step> <para>SystemTap then translates the script to C, running the system C compiler to create a kernel module from it. The tools that perform this step are contained in the <filename>systemtap</filename> package (refer to <xref linkend="installproper"/> for more information). </para> </step> <step> <para> SystemTap loads the module, then enables all the probes (events and handlers) in the script. The <command>staprun</command> in the <filename>systemtap-runtime</filename> package (refer to <xref linkend="installproper"/> for more information) provides this functionality. </para> </step> <!-- <step><para>SystemTap loads the module, then enables all the probed events by "hooking" those events into the kernel.</para></step> --> <step> <para> As the events occur, their corresponding handlers are executed. </para> </step> <step> <para> Once the SystemTap session is terminated, the probes are disabled, and the kernel module is unloaded. </para> </step> <!-- <step><para>Once the SystemTap session is terminated, the hooked events are disconnected from the kernel; afterwards, the kernel module is unloaded.</para></step>--> </procedure> <para>This sequence is driven from a single command-line program: <command>stap</command>. This program is SystemTap's main front-end tool. For more information about <command>stap</command>, refer to <command>man stap</command> (once SystemTap is properly installed on your machine). </para> </section> <xi:include href="Scripts.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <xi:include href="ScriptConstructs.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <xi:include href="Arrays.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <xi:include href="Array-Operations.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <!-- <section id="understanding-scripts"> <title>SystemTap Scripts</title> <remark> ** definition, significance, structure, very basic examples, reference to later chapter (how to read library of preset SystemTap scripts in this book, using them) </remark> </section> --> <section id="understanding-tapsets"> <title>Tapsets</title> <indexterm> <primary>Tapsets</primary> <secondary>definition of</secondary> </indexterm> <remark> definition, significance, difference with stap scripts (previous section), library of tapsets in system: location </remark> <para> <firstterm>Tapsets</firstterm> are scripts that form a library of pre-written probes and functions to be used in SystemTap scripts. When a user runs a SystemTap script, SystemTap checks the script's probe events and handlers against the tapset library; SystemTap then loads the corresponding probes and functions before translating the script to C (refer to <xref linkend="understanding-architecture-tools"/> for information on what transpires in a SystemTap session). </para> <!-- <para> Simply put, the tapset library is an abstraction layer designed to make it easier for users to define events and functions. In a way, tapsets provide useful "aliases" for functions that users may want to specify as an event; knowing the proper alias to use is, for the most part, easier than understanding how to specify a specific kernel function. </para> --> <para> Like SystemTap scripts, tapsets use the filename extension <filename>.stp</filename>. The standard library of tapsets is located in <filename>/usr/share/systemtap/tapset/</filename> by default. However, unlike SystemTap scripts, tapsets are not meant for direct execution; rather, they constitute the library from which other scripts can pull definitions. </para> <para> Simply put, the tapset library is an abstraction layer designed to make it easier for users to define events and functions. In a manner of speaking, tapsets provide useful aliases for functions that users may want to specify as an event; knowing the proper alias to use is, for the most part, easier than remembering specific kernel functions that might vary between kernel versions. </para> <!-- understanding how to specify a specific kernel function. --> <para> Several handlers and functions in <xref linkend="systemtapscript-events"/> and <xref linkend="systemtapscript-functions"/> are defined in tapsets. For example, <command>thread_indent()</command> is defined in <filename>indent.stp</filename>. </para> <remark> any other details to be included? i dont want to dwell too long here, though, since IMHO tapset development is beyond the scope of this "beginner's guide" </remark> </section> </chapter>