My setup comes from a complete novice approach to linux and network sharing
as I have only ever used windows.
This is my process for getting the computers up and running so I can plot
chia. This is the complete process from a computer with no OS to plotting
chia and getting the large samba process in memory.
- Install some form of linux (ubuntu, mint, pop, ect.) I have only been
using linux for a month so I have been exploring.
- do apt update, apt upgrade
- install samba
- copy these lines into smbd.comf
- client min protocol = NT1
- server min protocol = NT1
- usershare owner only = false
- force user = moursbourn (just because every computer I have is
logged into this username, and it stopped the permission issues I was
having)
- if the computer is the server
- create /mnt/storage
- sudo chmod -R 777 /mnt/storage
- *right click on the storage folder in the UI and share it from
there. *
-
- Install duf, htop, ssh, iftop
- Recently, I have added mergerfs onto the server as well.
- on the client (plotter)
- sudo mkdir /mnt/chiaPlots
-
- sudo chmod -R 777 /mnt/chiaPlots
- sudo mount -t cifs -o
username=moursbourn,file_mode=0777,dir_mode=0777 //192.168.1.6/storage
/mnt/chaiPlots
- install mad max chia plotter and start plotting to /mnt/chiaPlots
What I have noticed from looking at the Processes tab in System Monitor on
the server:
The server is on a 10GB network. When I start a chia plot (~106Gb file)
transfer from a client computer that is also connected to the 10Gb network
the transfer starts off at ~1000Mb/s until the samba process is larger than
32.5GiB. The largest I have seen is 39GiB. The transfer rate then drops
down to the hdd write speed of ~170Mb/s. That samba process never gets any
smaller than 32.5GiB. Even after the transfer is complete.
If a client computer that is connected with a 1Gb nic starts a transfer,
another samba process is spawned. That transfer stays around 130Mb/s to 150
Mb/s and the samba process grows to ~9GiB. After that transfer is complete
the process drops down to ~5MiB.
After a day of plotting and transferring ~100 plot files to the server from
those two computers there are still only the two samba processes running.
Plotting has been stopped for several hours and one is 32.5Gib, the other
is 4.9Mib.
The only other computer connected to the server is a windows 10 computer
running a farmer with the servers network share connected to it that would
be checking the plots as part of the chia farming process.
-matt
On Sun, Sep 12, 2021 at 1:44 AM Rowland Penny via samba <
samba at lists.samba.org> wrote:
> On Sat, 2021-09-11 at 12:50 -0700, Matt Oursbourn wrote:
> > All I do is add these lines to smb.comf under global.:
> > client min protocol = NT1
> > server min protocol = NT1
> > usershare owner only = false
> > force user = moursbourn
> >
> > I do not know what the NT1 stuff does other than it helped windows
> > see the share.
>
> It allows the use of SMBv1, which is required for network browsing.
>
> >
> > Here is the output:
> >
> > Load smb config files from /etc/samba/smb.conf
> > Loaded services file OK.
> > Weak crypto is allowed
> >
> > Server role: ROLE_STANDALONE
> >
> > # Global parameters
> > [global]
> > client min protocol = NT1
> > log file = /var/log/samba/log.%m
> > logging = file
> > map to guest = Bad User
> > max log size = 1000
> > obey pam restrictions = Yes
> > pam password change = Yes
> > panic action = /usr/share/samba/panic-action %d
> > passwd chat = *Enter\snew\s*\spassword:* %n\n
> > *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
> > passwd program = /usr/bin/passwd %u
> > server min protocol = NT1
> > server role = standalone server
> > unix password sync = Yes
> > usershare allow guests = Yes
> > usershare owner only = No
> > idmap config * : backend = tdb
> > force user = moursbourn
>
> Just about the only problem (and it is probably only a slight problem)
> is the use of 'force user', it is really only meant to be in a
share
> and I cannot understand why you added it.
>
> You also do not seem to have any shares apart from the 'homes'
share,
> what are you copying the data to/from ?
>
> Rowland
>
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba
>
On Sun, 2021-09-12 at 12:48 -0700, Matt Oursbourn via samba wrote:> What I have noticed from looking at the Processes tab in System > Monitor on > > the server: > > The server is on a 10GB network. When I start a chia plot (~106Gb > file) > > transfer from a client computer that is also connected to the 10Gb > network > > the transfer starts off at ~1000Mb/s until the samba process is > larger than > > 32.5GiB. The largest I have seen is 39GiB. The transfer rate then > drops > > down to the hdd write speed of ~170Mb/s. That samba process never > gets any > > smaller than 32.5GiB. Even after the transfer is complete.So one thing I would point out is that in unix memory management, the typical behaviour of malloc() is to be built on a low-level OS primitive called 'brk'. This is a high-watermark allocated by the kernel for the heap, the place where memory returned from malloc() lives. Once that memory is touched, it is owned by the process until process death. free() will only return it to the pool, not to the OS. So while I'm not saying everything is normal - Samba should not be holding GBs of files in memory waiting to write to the disk I would have thought - that is why even if we do a proper cleanup the process size won't ever shrink. However, what will shrink is the report from 'smbcontrol pool-usage', because our internal tracking will be that the memory is no longer allocated. What does this all mean? It means that the diff of that output between when the write is intensive and later, when the process is large but the write is concluded, would show what memory we were holding at write time, which might be excessive. I don't work on the file server, but perhaps we should throttle somehow? We used to be pretty syncronous with our write() path, but I understand this is is now async workers. Given the lower 'leak' result with the slower NIC, the mismatch between the network speed and the disk speed seems the likely trigger. One more thing: We can probably eliminate the newer io_uring code as that isn't in 4.11 where you first saw this. Andrew Bartlett -- Andrew Bartlett (he/him) https://samba.org/~abartlet/ Samba Team Member (since 2001) https://samba.org Samba Team Lead, Catalyst IT https://catalyst.net.nz/services/samba Samba Development and Support, Catalyst IT - Expert Open Source Solutions
On Sun, 2021-09-12 at 12:48 -0700, Matt Oursbourn wrote:> My setup comes from a complete novice approach to linux and network > sharing as I have only ever used windows. > > This is my process for getting the computers up and running so I can > plot chia. This is the complete process from a computer with no OS > to plotting chia and getting the large samba process in memory. > Install some form of linux (ubuntu, mint, pop, ect.) I have only been > using linux for a month so I have been exploring. > do apt update, apt upgrade > install samba > copy these lines into smbd.comf > client min protocol = NT1 > server min protocol = NT1 > usershare owner only = false > force user = moursbourn (just because every computer I have is > logged into this username, and it stopped the permission issues I was > having)In my opinion, you need to fix the permissions rather than sticking an extremely large bandage on it.> if the computer is the server > create /mnt/storage > sudo chmod -R 777 /mnt/storage > right click on the storage folder in the UI and share it from there.Ah, that explains why you do not any shares in smb.conf, you also may not be using Samba at all.> Install duf, htop, ssh, iftop > Recently, I have added mergerfs onto the server as well. > on the client (plotter) > sudo mkdir /mnt/chiaPlots > sudo chmod -R 777 /mnt/chiaPlots > sudo mount -t cifs -o > username=moursbourn,file_mode=0777,dir_mode=0777 > //192.168.1.6/storage /mnt/chaiPlotsYes, it looks more and more like you are not using Samba.> install mad max chia plotter and start plotting to /mnt/chiaPlots > What I have noticed from looking at the Processes tab in System>From my understanding about crypto currency (which is very limited),doesn't it cost more to mine the currency than what is returned ? It is, however, your computer. Rowland
Am 12.09.21 um 21:48 schrieb Matt Oursbourn via samba:> What I have noticed from looking at the Processes tab in System > Monitor on the server: The server is on a 10GB network. When I start > a chia plot (~106Gb file) transfer from a client computer that is > also connected to the 10Gb network the transfer starts off at > ~1000Mb/s until the samba process is largerthan> 32.5GiB. The largest I have seen is 39GiB. The transfer rate then > drops down to the hdd write speed of ~170Mb/s. That samba process > nevergets any> smaller than 32.5GiB. Even after the transfer is complete. > > If a client computer that is connected with a 1Gb nic starts a > transfer, another samba process is spawned. That transfer stays > around 130Mb/sto 150> Mb/s and the samba process grows to ~9GiB. After that transfer is > complete the process drops down to ~5MiB. > > After a day of plotting and transferring ~100 plot files to the > serverfrom> those two computers there are still only the two samba processes > running. Plotting has been stopped for several hours and one is > 32.5Gib, the other is 4.9Mib.the pool-usage of the large process you'd sent me privately contains: $ grep pthreadpool_tevent_job_state pool-usage\ smbd_32GiB.txt | wc -l 6468 which means there are 6468 SMB2 WRITE requests pending at the server. This is likely triggered because - the client is sending data much faster then the server is writing data to disk - Samba returns SMB2 Async Interim Response for every received WRITE request - These grant SMB2 credits to the client - As a result the client is not throttled by a crediting window Iirc we've seen this before some time ago and iirc a Windows server behaves either doesn't send interim async responses or stops sending them at some point. To me this looks like a design flaw in the crediting logic, but we can't change that so we have to adjust our write processing code to handle this. Until that fix materializes (which may take some tim) you could disable aio as a workaround in smb.conf by setting: aio read size = 0 aio write size = 0 -slow -- Ralph Boehme, Samba Team https://samba.org/ SerNet Samba Team Lead https://sernet.de/en/team-samba -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20210914/a8b5805b/OpenPGP_signature.sig>