I know, strange question.

 

My array is running at 94% of its space and has 270GB remaining.

 

Ya..I know I need another drive, but for now, i thought I would fill up what's there.

 

I can start my transfer , however within a few minutes I end up losing my connection to the array and the transfer stops.

 

There is nothing in my syslog when this happen ( note, the events in the syslog are all directly caused by me as I ran a parity check last night and I power cycled my switch this morning.  The issue with the time adjustments is an ongoing one where I lose time continually and the NTP re-sets it.  For now, the NTP is off, so that my syslog does show the hundreds of entries from the adjustments )

 

I was doing the file transfer at 8:40 and my last syslog entry is 8:21

 

Nov 25 14:53:06 Tower ntpd[1037]: time reset +1.781171 s

Nov 25 14:53:20 Tower ntpd[1037]: synchronized to 129.128.5.210, stratum 1

Nov 25 15:00:39 Tower ntpd[1037]: synchronized to 149.20.54.21, stratum 2

Nov 25 15:01:26 Tower ntpd[1037]: synchronized to 129.128.5.210, stratum 1

Nov 25 15:09:16 Tower ntpd[1037]: time reset +1.746867 s

Nov 25 15:09:43 Tower ntpd[1037]: synchronized to 149.20.54.21, stratum 2

Nov 25 15:12:42 Tower ntpd[1037]: synchronized to 129.128.5.210, stratum 1

Nov 25 15:24:45 Tower ntpd[1037]: time reset +1.879140 s

Nov 25 15:24:57 Tower ntpd[1037]: synchronized to 169.229.70.183, stratum 3

Nov 25 15:28:01 Tower ntpd[1037]: synchronized to 129.128.5.210, stratum 1

Nov 25 15:32:31 Tower emhttp: shcmd (669): ln -sf /usr/share/zoneinfo/Etc/GMT+5 /etc/localtime-copied-from

Nov 25 15:32:31 Tower emhttp: shcmd (670): cp /etc/localtime-copied-from /etc/localtime

Nov 25 15:32:31 Tower emhttp: shcmd (671): /etc/rc.d/rc.ntpd stop >/dev/null 2>&1

Nov 25 15:32:31 Tower ntpd[1037]: ntpd exiting on signal 15

Nov 25 15:32:32 Tower emhttp: _shcmd: shcmd (671): exit status: 1

Nov 25 15:32:32 Tower emhttp: shcmd (672): date -s '11/25/2009 3:32:24 PM' >/dev/null

Nov 25 15:32:24 Tower emhttp: shcmd (673): hwclock --utc --systohc --noadjfile

Nov 25 16:07:01 Tower emhttp: shcmd (674): /usr/sbin/hdparm -y /dev/sdb >/dev/null

Nov 25 16:07:02 Tower emhttp: shcmd (675): /usr/sbin/hdparm -y /dev/sdc >/dev/null

Nov 25 16:07:02 Tower emhttp: shcmd (676): /usr/sbin/hdparm -y /dev/sdd >/dev/null

Nov 25 16:07:12 Tower emhttp: shcmd (677): /usr/sbin/hdparm -y /dev/sde >/dev/null

Nov 25 16:07:12 Tower emhttp: shcmd (678): /usr/sbin/hdparm -y /dev/sda >/dev/null

Nov 25 20:10:57 Tower dhcpcd[1287]: sending DHCP_REQUEST for 172.16.0.103 to 172.16.0.1

Nov 25 20:10:57 Tower dhcpcd[1287]: dhcpIPaddrLeaseTime=86400 in DHCP server response.

Nov 25 20:10:57 Tower dhcpcd[1287]: DHCP_ACK received from (172.16.0.1)

Nov 26 00:02:58 Tower kernel: mdcmd (2321): check

Nov 26 00:02:58 Tower kernel: md: recovery thread woken up ...

Nov 26 00:02:58 Tower kernel: md: recovery thread checking parity...

Nov 26 00:02:58 Tower kernel: md: using 1152k window, over a total of 1465138552 blocks.

Nov 26 03:52:51 Tower emhttp: shcmd (679): /usr/sbin/hdparm -y /dev/sdc >/dev/null

Nov 26 04:51:58 Tower emhttp: shcmd (680): /usr/sbin/hdparm -y /dev/sdd >/dev/null

Nov 26 06:05:51 Tower kernel: md: sync done. time=21761sec rate=67328K/sec

Nov 26 06:05:51 Tower kernel: md: recovery thread sync completion status: 0

Nov 26 07:06:03 Tower emhttp: shcmd (681): /usr/sbin/hdparm -y /dev/sde >/dev/null

Nov 26 07:06:03 Tower emhttp: shcmd (682): /usr/sbin/hdparm -y /dev/sdb >/dev/null

Nov 26 07:06:04 Tower emhttp: shcmd (683): /usr/sbin/hdparm -y /dev/sda >/dev/null

Nov 26 08:10:57 Tower dhcpcd[1287]: sending DHCP_REQUEST for 172.16.0.103 to 172.16.0.1

Nov 26 08:10:57 Tower dhcpcd[1287]: dhcpIPaddrLeaseTime=86400 in DHCP server response.

Nov 26 08:10:57 Tower dhcpcd[1287]: DHCP_ACK received from (172.16.0.1)

Nov 26 08:21:12 Tower kernel: r8169: eth0: link down

Nov 26 08:21:12 Tower ifplugd(eth0)[1257]: Link beat lost.

Nov 26 08:21:23 Tower ifplugd(eth0)[1257]: Executing '/etc/ifplugd/ifplugd.action eth0 down'.

Nov 26 08:21:23 Tower logger: /etc/rc.d/rc.inet1: /sbin/dhcpcd -k -d eth0

Nov 26 08:21:23 Tower dhcpcd[1287]: sending DHCP_RELEASE for 172.16.0.103 to 172.16.0.1

Nov 26 08:21:24 Tower dhcpcd[1287]: terminating on signal 1

Nov 26 08:21:24 Tower ifplugd(eth0)[1257]: client: Stopping NTP daemon...

Nov 26 08:21:24 Tower ifplugd(eth0)[1257]: Program executed successfully.

Nov 26 08:21:25 Tower kernel: r8169: eth0: link down

Nov 26 08:21:41 Tower kernel: r8169: eth0: link up

Nov 26 08:21:41 Tower ifplugd(eth0)[1257]: Link beat detected.

Nov 26 08:21:42 Tower ifplugd(eth0)[1257]: Executing '/etc/ifplugd/ifplugd.action eth0 up'.

Nov 26 08:21:42 Tower ifplugd(eth0)[1257]: client: Polling for DHCP server on interface eth0:

Nov 26 08:21:43 Tower logger: /etc/rc.d/rc.inet1: /sbin/dhcpcd -d -t 30 -h Tower eth0

Nov 26 08:21:43 Tower kernel: r8169: eth0: link up

Nov 26 08:21:43 Tower dhcpcd[5563]: broadcasting DHCP_DISCOVER

Nov 26 08:21:44 Tower dhcpcd[5563]: broadcastAddr option is missing in DHCP server response. Assuming 172.16.0.255

Nov 26 08:21:44 Tower dhcpcd[5563]: dhcpIPaddrLeaseTime=86400 in DHCP server response.

Nov 26 08:21:44 Tower dhcpcd[5563]: DHCP_OFFER received from (172.16.0.1)

Nov 26 08:21:44 Tower dhcpcd[5563]: broadcasting DHCP_REQUEST for 172.16.0.101

Nov 26 08:21:44 Tower dhcpcd[5563]: dhcpIPaddrLeaseTime=86400 in DHCP server response.

Nov 26 08:21:44 Tower dhcpcd[5563]: DHCP_ACK received from (172.16.0.1)

Nov 26 08:21:44 Tower ifplugd(eth0)[1257]: client: dhcpcd: MAC address = 00:24:1d:82:a3:25

Nov 26 08:21:44 Tower ifplugd(eth0)[1257]: client: dhcpcd: your IP address = 172.16.0.101

Nov 26 08:21:44 Tower ifplugd(eth0)[1257]: client: dhcpcd: MAC address = 00:24:1d:82:a3:25

Nov 26 08:21:44 Tower ifplugd(eth0)[1257]: client: dhcpcd: your IP address = 172.16.0.101

Nov 26 08:21:44 Tower ifplugd(eth0)[1257]: Program executed successfully.

 

 

Is UnRaid just stopping the transfer as it wants to save the last 5% of my storage for.....something?

 

 

I am running version: 4.5-beta6 of UnRaid.  It's been running well since my last reboot on Oct.25th.  I know Tom is up to beta11, however I am always tentative about updating any of my software to beta releases.    If you guys think its stable and that I should update it, I will. 

 

Are you using user or disk shares on the transfer? What are your min free space settings?

270G, heck I've got drives smaller than that.  I'm with BRiT - I'm thinking you've got a min free space setting.

Thanks for the responses and sorry for the delay ( forgot to turn notification on.. i'm use to it being the default )

 

OK.. I do have shares setup in the main UnRaid menu.   The primary one ( and the one I copying over to ) is called "media".   I'm moving these particular files into a sub directory off of it caleed media/dvd

 

I have 4 other shares:

Other Files

Trailers

Music

xxx

 

The media share has no minimum free space set ( field is blank )

I have my share set to split level 4 ( as I didn't want any of the files spread over multiple drives )

 

So.. if I have no "min. free space" set, do you think/know if it just defaults to 5% of total space ?   If so, then that would make perfect sense why I can't use the last 270GB.  I would be a bit more useful if I got an error saying "Out of Space" or "Buy another Hard Drive, Dumbass" instead of the transferring failing because of lost conneciton ( or whatever it said ) 

 

 

If you copy files directly to the drive share itself (i.e. drive1 folder, drive2 folder, etc) you can fill the drives up as much as you want.  (until they're 100% full, of course)

 

Zithras

So, if I copy to the share /media/dvd ( that spans 4 drives ), I am then restricted to 95% then.

I don't believe that's true because I've screwed up and stuffed three of my drives to as little as ZERO free.

It sounds to me as if you may have a different issue, because you have said that the connection is lost, and that is not likely when running out of space.  Instead, you should see whatever error message that your transferring app normally displays on encountering what it thinks is a 'full disk'.  As a file server, unRAID should not display errors, just return appropriate error codes to your app, which should then display appropriate error messages.

 

Also, I don't think I have ever heard of anyone having an issue like this with 5% remaining free space.  When you fill to within the last few megabytes, it does get a little confusing, because the ReiserFS uses tail-packing and stuffing very small files within the file system b-trees, so the displayed free space is just an estimate, not actual.  But you should still be able to fill the drive to close to 100%, if not exactly 100%.

 

Why not set a 'Min free space' setting to something like 1000, which is about 1MB I believe.  But even if the default 'Min free space' setting is 5%, and that is causing issues, it does not explain why you are losing the connection.

I have changed min. settings to 1000, for all shares now.

 

I've just moved a 7GB file over without issue.

 

One other change I made was to my NTP.  I've shut it off.    I have an issue ( mentioned somewhere else in the forums ) where my server loses time -- constantly -- and with NTP Auto on, the server constantly "adjusts".  I wonder if these adjustments cause any type of blip in the network link ( like a small reboot )?

If NTP is off, then you aren't using it, nothing more.  It is just another tool, a useful service, but you don't have to use it if you don't want to.  You might consider scheduling a daily run of it though, since your clock loses about 3 minutes a day if I recall.  Start it with the -g option, so it will set the correct time, then terminate it a few minutes later.

 

Setting the Min free to 1000 is a way to essentially fill the disk to almost 100%, but it is probably wiser to set it higher, to larger than the largest file you may ever store on that drive.

 

Your loss of connection should have registered in the syslog.  The next time it happens, capture/examine your syslog, perhaps there will be a clue as to why it dropped.

I'm just in the process of freeing up another drive for the array.    Once I get it installed, that will give me another 1.5TB to work with.

 

I will then increase the min., as you suggested ( I figure 8GB is sufficient ).

 

 

When it comes to installing the new hard drive, I think that would be a good time to do a little troubleshooting with my clock losing time.  I've just avoided shutting the server off ( I hate to shut it off as its been running well, with the exception of losing time ).

 

I can't see it having anything to do with the CMOS battery ( even if it has one ) as my server has been on, so power should be coming form the AC.

 

Someone made a comment about my peripherals potentially creating an issue with the time.  I don't recall the reasoning.    Can I book the machine with the keyboard/mouse plugged in, then remove after or do I need to boot without either ( meaning I have to remove "hault on keyboard error" , or whatever its called in the BIOS.

 

Transferring of files BEFORE I shut off the NTP and set min. limits ALWAYS ended in network connection dropped.    Now, with those two things changed, I've moved 50GB without any issue.

 

I'm still wondering if the NTP adjustments ( when I had it on ) results in those brief drops that caused my file transfers to stop.

 

If anyone has a moment , I have attached my shortened syslog ( had to shrink it due to limited attachment sizes allowed on here ).