March 4, 201214 yr I am unable to create very large files on a disk from within Windows, even if there is sufficient space. The reason behind wanting such a large file is in order to create a Truecrypt container file (which would in theory fill at 1.5TB disk). I have tried attempting to create the file from truecrypt directly onto the disk, and also a file copy of a very large truecrypt file. As the file size is increased, the delay in creating the file increases. I imagine this would be due to having to create more entries in the file allocation table (or similar). If the file is too large, then windows returns with an error that the network share has disappeared. Any attempt to access any of the network shares on the machine will fail. The share in question has only one disk assigned to it, and attempting to use the disk share directly also fails. I checked the syslog as I did this and also had a look at the two logs within /var/log/samba and didn't see anything of interest appear. I nontheless enclose a syslog. I believe the filesystem will support files up to at least 2TB and the same for Samba. From experimentation the maximum size file I can create appears to be around 750GB. Is there some other limit I am not aware of? I could potentially remove the disk, boot up a linux system from a recovery disk and create the file onto that, before returning the disk to unraid, but this seems very hacking and if the problem is one of addressing, then part of the disk will be inaccessible / corruption issues will present themselves. The system I am using is based around the Gigabyte GA-D425TUD board. This does have a network chipset which I believe people have had issues with, but up until this point I have had no issues whatsoever with my server, which has been running for over a year. I am not using any addons, other than a small script for adjusting the fan speed of the front case fan every couple of minutes based on HDD temperatures. Any help would be appreciated syslog.txt
March 5, 201214 yr UnRAID does not stripe. If the disk being written only has 750GB of free space then that is the largest files that can be written.
March 5, 201214 yr Are you using user shares or direct access to disk? I.e. //tower/disk1? Sent from my SGH-I727R using Tapatalk
March 5, 201214 yr Author The disk that is being written to is empty i.e has ~1.4TB of free space, so there would be no need for striping. I have tried using a share name and also trying to write directly to the disk. And just for fun, I also tried using NFS, which times out even faster. Whilst I remember I'm using version 4.7 (with no mods)
March 5, 201214 yr Have you tried the linux version of truecrypt directly on unraid? Not sure it can run, but if has a command line interface it might. Sent from my SGH-I727R using Tapatalk
March 5, 201214 yr Author I haven't tried the linux version of truecrypt, and I would prefer not to deploy it onto an unraid server as I personally believe a fileserver should be as simple as possible to maintain its trustworthyness. I think the idea you propose is also a workaround rather than confronting the main issue, which appears to be that it is not possible, at least for myself, to create very large files on an unraid server. If other people have managed this without any issues that would be useful to know as it might limit the problem to my setup rather than a general problem with unraid.
March 7, 201214 yr Author Any thoughts? Surely someone else must have created a very large file on their server before?
March 9, 201214 yr I've done the same thing as you, only up to 500GB though. I do recall that using the unRAID 4.5 series and an older version (the 6.x series I think) of TrueCrypt I couldn't get past about 200GB. What I did then to get around this was to do the TrueCrypt creation on a drive that was USB attached to the Windows box, then once TrueCrypt was done I moved the drive over to the unRAID box (still USB attached) and copied the TrueCrypt file (from the command shell) onto a drive that was part of the RAID set (this avoided any use of SAMBA). The problem at the time was with SAMBA's way of allocating a large file and this was addressed (or so I thought) with the version of SAMBA that comes with unRAID 4.7. Regards, Stephen
Archived
This topic is now archived and is closed to further replies.