xfs
[Top] [All Lists]

Re: ProFTPd + linux-2.4.2-XFS = RETR bug

To: J Kinsley <jkinsley@xxxxxxxxx>
Subject: Re: ProFTPd + linux-2.4.2-XFS = RETR bug
From: Steve Lord <lord@xxxxxxx>
Date: Fri, 16 Mar 2001 11:12:33 -0600
Cc: proftpd-users@xxxxxxxxxxx, proftpd-devel@xxxxxxxxxxx, linux-xfs@xxxxxxxxxxx
In-reply-to: Message from J Kinsley <jkinsley@xxxxxxxxx> of "Fri, 16 Mar 2001 12:03:19 EST." <Pine.LNX.4.30.0103160413420.27608-100000@xxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
This is almost certainly not proftpd, but something about xfs, if possible
can you download the cvs version of the kernel, Feb 23 is a long time ago
as far as xfs is concerned now, and I would like to determine if the
problem is still present in xfs. 

Steve

> I am running ProFTPd 1.2.1 on an experimental Redhat 7.0/7.1beta
> (glibc-2.2) PII box.  The kernel is the stock 2.4.2 specifically
> configured for the box it is running on.  The only patch applied
> is the Feb232001devel XFS patch from SGI.
> 
> (ftp://linux-xfs.sgi.com/projects/xfs/download/patches/Feb232001devel.patch.g
> z)
> 
> Both the kernel and XFS tools were compiled using egcs-1.1.2 (kgcc on
> RH70) while ProFTPd and everything else were compiled with the RH71
> gcc.
> 
> I have ProFTPd configured with one master server and two virtual
> hosts.  The DefaultRoot for each site is on separate partition or
> disk. All partitions were created using the mkfs.xfs command from the
> XFS patch kit.  In addition, the DefaultRoot of the two virtualhosts
> is accessable via the web using Apache-1.3.19 which works properly.
> 
> The bug arises when the remote client attempts to RETR a file with
> filesize >= 16384.  The file is received by the remote as an empty
> file (filesize ==0) with all remaining file attributes (name, mtime,
> etc) preserved.  However, if a particular file with filesize >= 16384
> has recently been accessed by some other process such as Apache, then
> the remote FTP client can receive the complete file irregardless of
> its filesize.  Once a period of time passes after the file has been
> accessed by another process, the file will again be returned empty to
> the remote FTP client.  I have not yet determined what the exact
> period of time is, but on averate it is one hour.  Files with
> filesize < 16384 seem to be uneffected by this bug.
> 
> For those that want to observe this bug in action, goto:
> 
> ftp://ftp.freeworldbbs.org:4021/
> 
> The subdirectory, xfs-test contains contains five test files.  The
> filesizes are 8192, 16383, 16384, 16385, and 32768.  The first two
> files will always be retrieved while the last three will be empty
> files when retrived.  Since I just copied the files to a parallel
> FTP tree, I can now download all of them via the remote client.
> 
> The parallel FTP tree is identical to the one here except that it is
> stored on an ext2 filesystem.  It can be accessed at:
> 
> ftp://ftp.freeworldbbs.org/
> 
> The ProFTPD configuration for the two sites is identical with the
> exception of /mnt being appended to the paths and a Port 4021
> directive being aded in the first one.
> 
> I have been using ProFTPd for several years without incident, and now
> that I have tried XFS, I certainly do not want to deevolve my box
> back to ext2.  Unfortunately, my skills are not at the level required
> to go poking around in the kernel, XFS, and ProFTPd to figure out a
> solution to this problem.  However, I can test any possible patches
> to ProFTPd.
> 
> 
> Regards,
> Jarrod Kinsley



<Prev in Thread] Current Thread [Next in Thread>