I will try to provide as many details as possible but this one has me scratching my head...

A few months ago I was asked to set up a test syslog server for internal use only. I chose to go the following route for simplicity:

1. I used Gentoo Linux so that I could have the most stripped down and highest performing box possible for the task
2. I also decided to use the Xen virtualization system so that I could easily migrate this server from this box to any other Xen box with minimal or no downtime
3. I chose syslog-ng as the syslog server since it was part of Gentoo's portage archives
4. I used the ReiserFS for all filesystems including the dedicated syslog filesystem

Xen details:

1. After installing the base Gentoo distro, I installed Xen from source and compiled a new kernel with support for everything I needed including the ReiserFS
2. I took the primary disk device and used LVM (again for simplicity's sake sinc e it's much more flexible than partitions) to slice it up for Domain0 (the "host" OS for lack of a better term) and the other domains, one of which was my syslog server
3. I then built my syslog VM (Domain1) based off the stripped down base OS for Domain0 on an LVM and unmounted it in Domain0
4. The new vg was then mounted as ReiserFS within Domain1 and I booted
5. I then emerged syslog-ng and got it configured to work as needed

Everything seemed fine. I was able to capture syslog... no problem. For one day's worth of Pix data I had a 48 Gigabyte syslog file. This is where the problem comes in. It appears the ReiserFS has no problem handling the file size. But if I attempt to transfer it off to any other system using FTP I get an error. I thought it might have something to do with the target system's file system. But one of the boxes I was testing with was an HP-UX box with vxfs and the largefiles option enabled. It SHOULD be able to handle a 48 gigabyte file. So to test further I decided to create a file that was slightly less than 4 gigs and see if it would transfer. Still didn't work. IN fact the only way a file will transfer is if I'm below 2 gigs. This is where I'm a bit confused. If the filesystem that currently contains the file can handle super large files, then why won't it transfer those files using FTP? See below:

FTP gives me the following:

Code:

ftp> get pix.log
local: pix.log remote: pix.log
200 PORT command successful.
550 pix.log: not a plain file.

I've tried pushing the files from the syslog server (ftp client) to the target hosts (ftp server). And I've tried pulling from the syslog server (ftp server) to the target hosts (ftp client). The target hosts have all been either Unix (Linux, Solaris, HP-UX) or VMS boxes. The VMS box is the final target actually and the other Unix boxes were just used to try and troubleshoot this problem. The VMS box is using a version of the RMS filesystem that can also support files larger than 2 gigs. I was only able to successfully copy the large file to another Linux box using scp. Multinet's SCP on the OpenVMS box fails with the following error:

Code:

VMS_I> scp2 "root@10.0.1.1::/logs/pix.log" test.fil
root@10.0.1.1's password: 
SCP2: FATAL: DISK$MULTINET_V44_A:[MULTINET_V44A.MULTINET.SSH2.APPS.SSH]SSHFC_TRA
NSFER.C;1:3004 SshFCTransfer (function name unavailable) Assertion failed: tdata
->read_bytes <= tdata->source_file->attributes->size

Finally I also tried running a Samba server on the syslog server and using DEC's SMB client to copy the file but it failed after copying 2 gigs. Note; the underlying file system (RMS) does not have a 2 gig file limitation. I suspect that the SMB implementation from DEC is the limitation here.

Anyone have any ideas?