I just upgraded one of my volumios to a 256GB sd card (high speed video spec)
It all looks fine and the overlay is almost 246GB.
I started copying over music (to internal storage) from my windows PC but after only about 15GB the copy stopped saying there was no space. After a lot of messing around I’ve discovered that I can copy music in small batches with pauses - I’m up to about 30GB of files now, but I’m baffled as to what’s going on. Why is there a speed limit? Is there some processing that Volumio needs to do to keep creating new space for music?
Addendum. I can copy large numbers of files successfully using a Windows app such as Teracopy, while a synchronising app such as Goodsync fails with a disk space error (on the first file). I don’t think this is a Volumio issue as such, but there’s certainly something odd going on when copying from a Windows (Server) to Volumio internal storage across a wired network. But I have a workaround for now.
This could be a copy problem within Linux itself. What version of Linux are you using? I found that Linux 4.x copying (using cp function) fails because it runs out of free memory and needs to be rebooted to recover. I do bulk copies by plugging the Volumio SD card into a Windows PC and do the bulk copy that way (I’m using a FAT32 partition for the music). 300GB of music copied in 2.5 hours. I also use NAS for copying smaller volumes of data which works fine, but is somewhat slower than doing the direct copy.
Then transfer the music via SFTP, start your favorite FTP program, connect via SFTP on port 22, log in with user accounts (username: volumio / password: volumio).
I would also recommend that you change the password with the command sudo passwd volumio
You underestimate the readiness of people to only do “cut&paste” without knowing what they are doing. They don’t need to be an expert, but as a valued community member, you are not really helping here, letting us deal with the problems following your ill advice.
Speed limit is a bit ambiguous. SD card write has own capabilities, memory buffer as well, so does the network with bandwidth.
I think that you are facing different problem. MS Windows standard rlimit ( establishes a restricting boundary on the consumption of a variety of system resources by a process) is 16384 and as such is backed by rss (The Resident Set Size is the amount of pages currently present in RAM) allows large file collection buffering. Volumio is offered for devices with as little as 256MB of total RAM and there is no golden rule (yet) how to dynamically mange limits. By stating that, the Volumio OS file daemon (samba) only permits rlimit of 1024.
Hence why restricted buffers capability responds with something like “Hold on, I need to write what I have in my buffer to the storage first, before I will accept more”. MS Windows responds “Are you kidding? You do not have space? I will let my user know! Shame on you”.
It is all about timing and fundamentals of TCP protocol too. Volumio OS whilst busy writing will not respond with ACK (acknowledge) frame, and this is likely flagged as transmit error to which MS Windows likely responds “You are not talking to me? Have the same batch again!”
Of course, technically presented chat is much more complex, however the high level of it explains the challenge.
With the above in mind, why smaller file collections are successful whilst large ones are not, is quite apparent.