is er een slimmer Samba?

[HollowGamer]

Een beetje vage titel, hopelijk helpt mijn voorbeeld.

Setup:
1x SSD (ext4) op /
2x HDD 2TB (Btrfs RAID 1) op /mnt/data
1x HDD 2TB (ext4) op /mnt/tmp
Intel i3 (Skylake)
Arch Linux

De /mnt/tmp gebruik ik voor mijn downloads, compile stuff, etc. Nu komt het wel vaker voor dat ik uiteindelijk toch iets wil bewaren en dit verplaatst naar /mnt/data. Dit doe ik altijd via de server zelf omdat over Samba dit langer duurt (gebruik /mnt als share).

Is er een 'Samba' die de mv actie(s) doet op de server zelf en niet via mijn netwerk?

Verder ben ik aan het denken om te switchen naar NFSv4, maar vind ik nogal tegenstrijdige berichten over de snelheid en lees ik over bugs. Kan iemand mij daar meer over vertellen?

Alvast bedankt!

[Lethalis]

Of je SAMBA of NFS gebruikt, lijkt me nogal afhankelijk van de clients. Ik gebruik eigenlijk altijd SAMBA, omdat het lekker compatibel met alles is (Linux, Windows, OS X, etc).

Wat de eigenlijke vraag betreft, geen idee. Misschien kun je dit via de download software doen? Stel je gebruikt bepaalde software om te downloaden op de server, dat je via deze software eenvoudig kunt zeggen dat het naar /mnt/data moet als je iets wil bewaren (stel de software kan custom scripts uitvoeren).

M.a.w. misschien kun je dit op de server anders oplossen.

[HollowGamer]

Lethalis schreef op dinsdag 25 april 2017 @ 11:50:
Of je SAMBA of NFS gebruikt, lijkt me nogal afhankelijk van de clients. Ik gebruik eigenlijk altijd SAMBA, omdat het lekker compatibel met alles is (Linux, Windows, OS X, etc).

Wat de eigenlijke vraag betreft, geen idee. Misschien kun je dit via de download software doen? Stel je gebruikt bepaalde software om te downloaden op de server, dat je via deze software eenvoudig kunt zeggen dat het naar /mnt/data moet als je iets wil bewaren (stel de software kan custom scripts uitvoeren).

M.a.w. misschien kun je dit op de server anders oplossen.

Ik denk inderdaad dat er niets anders opzit dan het gewoon op één (RAID-)schijf te houden, i.p.v. nu twee HDD's. Het is opzicht niet erg de vertraging, maar inderdaad heb ik dan geen issues meer.

Bedankt.

[heuveltje]

HollowGamer schreef op dinsdag 25 april 2017 @ 08:24:
Een beetje vage titel, hopelijk helpt mijn voorbeeld.

Setup:
1x SSD (ext4) op /
2x HDD 2TB (Btrfs RAID 1) op /mnt/data
1x HDD 2TB (ext4) op /mnt/tmp
Intel i3 (Skylake)
Arch Linux

De /mnt/tmp gebruik ik voor mijn downloads, compile stuff, etc. Nu komt het wel vaker voor dat ik uiteindelijk toch iets wil bewaren en dit verplaatst naar /mnt/data. Dit doe ik altijd via de server zelf omdat over Samba dit langer duurt (gebruik /mnt als share).

Is er een 'Samba' die de mv actie(s) doet op de server zelf en niet via mijn netwerk?

Verder ben ik aan het denken om te switchen naar NFSv4, maar vind ik nogal tegenstrijdige berichten over de snelheid en lees ik over bugs. Kan iemand mij daar meer over vertellen?

Alvast bedankt!

Niet specifiek voor samba, maar misschien een ideetje.
Ik zelf gebruik 1 schijf op mijn pc voor downloaden, en 12 andere voor opslag.
1 keer in de zoveel tijd wil ik alles opruimen, maar geen zin om te wachten op al die kopie slagen.

Dus ik heb op die download schijf een folder gemaakt "klaar voor verplaatsen"met daarin een voor elke schijf een eigen folder. Ik verplaats alles naar die dir. En een simpel python scriptje wat 1 keer per uur draait verplaatst alles uit de desbetreffende dirs naar de bijbehorende schijf.

Nu heb ik dat specifiek geschreven voor mijn windows server, dus daar heb je niks aan.
Maar er is vast wel een manier om een soortgelijk "move files" idee te scripten in linux mbv cronjob

[Daedalus]

Wat je zoekt is Server-Side Copy. Of dit werkt is afhankelijk van het OS van je clients (voornamelijk Windows 7/8 of later, of bepaalde Linux tools met de juiste commando's, geen macOS).

[ Voor 3% gewijzigd door Daedalus op 25-04-2017 15:13 ]

[CAPSLOCK2000]

Je hebt SMB 4.3 of NFS 4.2 nodig. Dat is allemaal nogal nieuw en niet breed ondersteunt. Ik heb geen idee of het in de praktijk ook echt werkt. Ik zou er niet te hard op rekenen.

[HollowGamer]

heuveltje schreef op dinsdag 25 april 2017 @ 15:06:
[...]


Niet specifiek voor samba, maar misschien een ideetje.
Ik zelf gebruik 1 schijf op mijn pc voor downloaden, en 12 andere voor opslag.
1 keer in de zoveel tijd wil ik alles opruimen, maar geen zin om te wachten op al die kopie slagen.

Dus ik heb op die download schijf een folder gemaakt "klaar voor verplaatsen"met daarin een voor elke schijf een eigen folder. Ik verplaats alles naar die dir. En een simpel python scriptje wat 1 keer per uur draait verplaatst alles uit de desbetreffende dirs naar de bijbehorende schijf.

Nu heb ik dat specifiek geschreven voor mijn windows server, dus daar heb je niks aan.
Maar er is vast wel een manier om een soortgelijk "move files" idee te scripten in linux mbv cronjob

Dit doe ik nu aan de hand van een bash script, opzicht gaat dit prima, maar dan moet ik inderdaad elk halfuur wachten of dit forcen, wil er dus vanaf dat ik elke keer moet inloggen op de server.

CAPSLOCK2000 schreef op dinsdag 25 april 2017 @ 17:32:
Je hebt SMB 4.3 of NFS 4.2 nodig. Dat is allemaal nogal nieuw en niet breed ondersteunt. Ik heb geen idee of het in de praktijk ook echt werkt. Ik zou er niet te hard op rekenen.

Beide heb ik zo te zien: smbclient/samba 4.5.8
Ik gebruik momenteel op alle clients Linux en beide zitten op dezelfde versie.
Misschien zit de bottleneck in de twee HDD's?

[TheBorg]

Een bestand verplaatsen binnen een share gebeurd server side. Echter als je twee verschillende shares hebt, data en tmp, dan krijg je een copy/delete.

Wellicht werkt het ook met een symlink in /mnt naar /tmp.

[HollowGamer]

TheBorg schreef op woensdag 26 april 2017 @ 09:52:
Een bestand verplaatsen binnen een share gebeurd server side. Echter als je twee verschillende shares hebt, data en tmp, dan krijg je een copy/delete.

Wellicht werkt het ook met een symlink in /mnt naar /tmp.

Thanks, dat wist ik niet.
Ga overschakelen naar één mountpoint en gewoon op /mnt/data wegschrijven, moet vaak deze bestanden overzetten, dus dan is dit wellicht een betere keuze.