Re: posix_fallocate

Krzysztof Błaszkowski
2010-05-07T10:05:33Z

Hello Stan,

It seems that your mail server blocks traffic from ".pl" domains so don't be
offended if you will not see my reply sent to your address.

(Remote host said: 550 5.7.1 <v007470.home.net.pl[212.85.125.104]>: Client
host rejected: We do not accept mail from .pl domains)

Krzysztof

On Friday 07 May 2010 11:23, Stan Hoeppner wrote:
> Krzysztof Błaszkowski put forth on 5/7/2010 3:22 AM:
> > Hello,
> >
> > I use this to preallocate large space but found an issue. Posix_fallocate
> > works right with sizes like 100G, 1T and even 10T on some boxes (on some
> > other can fail after e.g. 7T threshold) but if i tried e.g. 16T the user
> > space process would be "R"unning forever and it is not interruptible.
> > Furthermore some other not related processes like sshd, bash enter D
> > state. There is nothing in kernel log.
> >
> > I made so far a few logs with ftrace facility for 1G, 100G, 1T and 10T
> > sizes. I noticed that for 1st three sizes the log is as long as abt 1.5M
> > (2M peak) while 10T generates 94M long log. I couldn't retrieve a log for
> > 17T case because "cat /sys ... /trace" enters D.
> >
> > I would appreciate any help because i gave up with ftrace logs analysis.
> > The xfs_vn_fallocate is covered in abt 11k lines for a 1.5M log case
> > while there are abt 163k lines in 94M log. And all i could see is poss
> > some relationship between time spent in xfs_vn_fallocate subfunctions vs
> > requested space.
> >
> > Box details:
> > 16 Hitachi 2TB drives (backplane connected), dm, 1 lvm lun of 25T size,
> > kernel 2.6.31.5, more recent kernels neither xfs were not tested.
>
> 32 or 64 bit kernel? What is the size of the XFS filesystem on the 25TB
> LVM LUN against which you're running posix_fallocate? The reason I ask is
> that XFS has a 16TB per filesystem limitation on 32 bit kernels. I can
> only assume that your XFS filesystem is larger than 16TB since you're
> attempting to posix_fallocate 16TB. But, it's best to ask for confirmation
> rather than assume, especially given that your problem is appearing near
> that magical 16TB boundary.