Subject: Re: smbd dies under heavy transfers
To: Chuck Swiger <firstname.lastname@example.org>
From: Andy Ruhl <email@example.com>
Date: 04/16/2007 14:01:04
On 4/16/07, Chuck Swiger <firstname.lastname@example.org> wrote:
> If you're asking the Samba server to simply copy files from one
> location to another on the fileserver, it can do so without having to
> send the contents of all of those files to the client machine.
Shouldn't be doing that, but I do understand this process. You can
move a large number of files on the fileserver with no network
> If you're using iTunes to process those files, it is probably reading
> them and then writing them back out, which involves a lot more data
> going back and forth in transit.
I need to figure out for myself if "process" means "read" or
"read/write". I never tested with the file server set to "readonly". I
don't use iTunes to rip or otherwise create some music file. I do all
that myself on NetBSD (with abcde from pkgsrc, works great). I assume
(probably poorly) that it's only reading files.
> iTunes is multithreaded, but I believe that iTunes attempts to
> serialize access to USB devices (ie, notably iPods). However, it
> will perform some operations on your "song library" kept on disk in
> parallel, especially when doing certain one-time updates like trying
> to D/L album covers or figure out volume auto-leveling or gapless
> playback information.
I don't know if iTunes actually changes mp3 files it didn't create? I
semi-tested this by trying to tag files with iTunes and it didn't
actually tag the mp3 file. I assume it's keeping the tag info in it's
database, or something.
> Samba does attempt to pre-read something like 32K or 64K of each file
> being accessed when a client opens it, but there is a tunable in
> smb.conf that you might want to play around with. 
I suppose that could be a problem if you're doing a whole lot of reads
in parallel. But it seems surprising that iTunes could do this much
parallel reading itself... That seems like a whole lot of threads...
> If you can gather more specific info into a reproducible test-case,
> please consider filing a bugreport against iTunes at https://
I'm generally happy so far... I will say that I think iTunes seems to
try to do too much I/O sometimes and it's a pain when the I/O path is
relatively slow (in the case of a Samba server, for instance). Not
sure it's worth a bug report.