Samba traag: Verplaats bestand binnen de server via windows

[JaWSnl]

Sinds kort maak ik gebruik van een Samba file-server met als OS Ubuntu Server.

Als ik een bestand zou verplaatsen via unix dan zou ik bijvoorbeeld gebruiken:

code:

mv /home/user/download/source/film.avi /srv/samba/share/destination

Dit gebeurt dan in enkele milliseconden.

In windows (xp en vista) heb ik een browsable folder, verbonden als 'netwerkschijf'.
Als ik dan een bestand wil verplaatsen (cut-paste) BINNEN de server, dan is dat super traag. We werken hier via een draadloze verbinding, en daarom gaat dit waarschijnlijk met slechts 2 MB/s. MAAR: Waarom gaat dit via mijn computer? Waarom kan het niet gewoon op de server zelf uitgevoerd worden d.m.v. het mv-command?

Is er een instelling in samba die er voor zorgt dat dit wel gewoon lokaal op de server gebeurd?

(ik heb gezocht via google maar hier vind je vrijwel alleen antwoorden over het verplaatsen van bestanden van server naar client-pc)

[swbr]

Nee, zo'n instelling is er niet.

[JaWSnl]

Antaresje schreef op dinsdag 23 november 2010 @ 14:33:
Nee, zo'n instelling is er niet.

Is er dan een manier om het sneller te doen? Of kan het alleen maar snel met het mv-command?

[arie_papa]

Remote desktop naar server > mv

[DutchNutcase]

Als je pc een bestand verplaatst binnen een lokale schijf wordt normaal gesproken gewoon de Inode aangepast en dat is dat. Maar als je van een netwerkschijf werkt kan je OS de Inode niet wijzigen en moet dus eerst het bestand ergens gecached worden (je RAM) om vervolgens weer op de juiste plek terug te zetten.

Het verplatsen van (grote) bestanden binnen je server kun je dus het beste op de server doen.

[deadinspace]

JaWSnl schreef op dinsdag 23 november 2010 @ 14:25:
Sinds kort maak ik gebruik van een Samba file-server met als OS Ubuntu Server.
In windows (xp en vista) heb ik een browsable folder, verbonden als 'netwerkschijf'.
Als ik dan een bestand wil verplaatsen (cut-paste) BINNEN de server, dan is dat super traag.

SMB ondersteunt voorzover ik kan achterhalen wel renames, en daarmee zou ik verwachten dat het ook moves ondersteunt (da's namelijk hetzelfde).

Wat vraagjes:

• Verplaats je bestanden wel binnen dezelfde share? Als je files verplaatst tussen twee shares, dan kan ik me goed voorstellen dat dat mis gaat, ook al bevinden die twee shares zich op dezelfde server.
• Bevinden beide paden zich op de server binnen hetzelfde filesystem (dus niet tussen /tmp en /home als /home een apart fs is)? Dat is wel een vereiste.
• Kun je op je share wel snel files renamen ipv moven?

DutchNutcase schreef op dinsdag 23 november 2010 @ 16:36:
Als je pc een bestand verplaatst binnen een lokale schijf wordt normaal gesproken gewoon de Inode aangepast en dat is dat.

De inode wordt juist niet aangepast

(de dentries worden aangepast)

[DutchNutcase]

deadinspace schreef op dinsdag 23 november 2010 @ 17:04:
[...]

De inode wordt juist niet aangepast

(de dentries worden aangepast)

offtopic:
U heeft gelijk. Ik ben abuis.

[sub0kelvin]

deadinspace schreef op dinsdag 23 november 2010 @ 17:04:
[...]

SMB ondersteunt voorzover ik kan achterhalen wel renames, en daarmee zou ik verwachten dat het ook moves ondersteunt (da's namelijk hetzelfde).

Hij zegt "cut - paste" te gebruiken om te verplaatsen. Het zou me niks verbazen als dat binnen shares niet als move wordt gezien maar als "copy - paste - delete".

@TS: werkt slepen wel?

[_Squatt_]

Cut/paste en slepen van een ~4 gb bestand zijn hier beide instant. Dit is wel binnen dezelfde share, van een Vista client naar een samba 3.4.8 server.

Heb zelf geen tweede share om mee te testen, maar daar verwacht ik wel een copy+delete in plaats van een move.

[JaWSnl]

Bedankt voor al het meedenken!

Ik heb even getest wat wel en niet snel gaat. Het verplaatsen van een bestand via de windows browser gaat wel instant ALS er binnen dezelfde share gebleven wordt. Of ik een bestand nou sleep of crtl-X, ctrl-V gebruik maakt dan niet uit.
Slechts als ik het tussen shares verplaats gaat het langzaam.

De verschillende shares bevinden zich wel overigens binnen 1 bestandssysteem.

Is er een manier om dit te verbeteren? Wederom geeft google me alleen informatie over het verplaatsen tussen windows en linux. Iets veranderen aan de owner of group veranderd ook niks.

[Mijzelf]

JaWSnl schreef op woensdag 24 november 2010 @ 15:21:
Slechts als ik het tussen shares verplaats gaat het langzaam.

De verschillende shares bevinden zich wel overigens binnen 1 bestandssysteem.

Is er een manier om dit te verbeteren?

Volgens mij alleen via een 'supershare'. Wanneer al je shares zich binnen /home bevinden, dan zou je van /home ook een share kunnen maken, zodat je de verplaatsing hierbinnen kunt houden.

[sub0kelvin]

Ik heb hier niet de mogelijkheid om het te testen, maar is dat niet altijd zo wanneer er tussen shares gemoved wordt? Dus ook indien de server een Windows-PC is?

Het lijkt me namelijk dat shares geen kennis van elkaar hebben (op welk file-system e.d.) en dat de client dus bij voorbaat een copy zal doen. Maar goed, dit is op basis van vermoedens, niet van testen of uitzoeken.

[Kompaan]

JaWSnl schreef op woensdag 24 november 2010 @ 15:21:
Slechts als ik het tussen shares verplaats gaat het langzaam.

Client kan aan de buitenkant niet zien of die shares op dezelfde schijf/FS/whatever zitten. Zal dus altijd kopiëren als iets vanaf een share naar ergens anders gaat.

[bredend]

Workaround:
Maak op share1 een mapje 'out' aan en op share2 een mapje 'in'. Op de server laat je een programmatje draaien dat alle bestanden van mapje 'out' naar mapje 'in' verplaatst.

Dan sleep je bestanden binnen share1 naar 'out' en haal je ze er op share2 weer uit het mapje 'in'!

[Kompaan]

bredend schreef op woensdag 24 november 2010 @ 15:46:
Workaround:
Maak op share1 een mapje 'out' aan en op share2 een mapje 'in'. Op de server laat je een programmatje draaien dat alle bestanden van mapje 'out' naar mapje 'in' verplaatst.

Dan sleep je bestanden binnen share1 naar 'out' en haal je ze er op share2 weer uit het mapje 'in'!

Mooie! Ik ga zo'n mapje maken (downloads -> archief)