xfs
[Top] [All Lists]

Re: O_DIRECT wierd behavior..

To: "XFS: linux-xfs@xxxxxxxxxxx" <linux-xfs@xxxxxxxxxxx>
Subject: Re: O_DIRECT wierd behavior..
From: "D. Stimits" <stimits@xxxxxxxxxx>
Date: Sat, 15 Dec 2001 22:09:50 -0700
References: <Pine.GSO.4.02A.10112152215340.26029-100000@xxxxxxxxxxxxxxxxxx> <3C1C2A82.6FD7489A@xxxxxxxxxx>
Reply-to: stimits@xxxxxxxxxx
Sender: owner-linux-xfs@xxxxxxxxxxx
"D. Stimits" wrote:
> 
> Suresh Gopalakrishnan wrote:
> >
> > On Sun, 16 Dec 2001, Keith Owens wrote:
> > > On Sat, 15 Dec 2001 21:24:52 -0500 (EST),
> > > Suresh Gopalakrishnan <gsuresh@xxxxxxxxxxxxxx> wrote:
> > > >open("/tmp/blah", O_RDWR|O_CREAT|O_DIRECT, 0) = 3
> > > >write(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> > > >8192) = -1
> > > > EINVAL (Invalid argument)
> > > >fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 7), ...}) = 0
> > > >mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> > > >= 0x40
> > > >018000
> > > >ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
> > > >write(1, "write returns -1\n", 17write returns -1
> > > >)      = 17
> > > >write(3, "\0", 1)                       = -1 EFBIG (File too large)
> > > >--- SIGXFSZ (File size limit exceeded) ---
> > > >+++ killed by SIGXFSZ +++
> > >
> > > This is a side effect of omitting the create mode on open.  It picks
> > > up garbage from stack instead of the mode, in this run it picked up
> > > mode 0, no access at all.  Something in the kernel is trapping write
> > > to a file opened with no access and returning EFBIG, which glibc
> > > converts to SIGXFSZ. Use a valid mode on open with O_CREAT.
> > > Otherwise you pick up stack garbage which can vary from one compile to
> > > another.
> >
> > Hmm.. With 0777 mode argument, it just creates a huge file with the
> > appropriate permissions (after umask).. same errors.. :(
> >
> > -rwxr-xr-x    1 gsuresh  users    4294967274 Dec 15 22:14 /tmp/blah
> >
> > --suresh
> 
> Interesting number, hex it is 0xFFFFFFEA. Hex 0x15 off from nice round
> power of 2 minus 1, 0xF from turning over a 32 bit number. Not really

Correction, 0x16 or 22 decimal from turning it over. Never use a hex
calc :)

> helpful, but I would expect in most cases it would be a number exactly
> 2^x - 1. Where do the last 0x15 bytes go? Is that some kind of overhead
> granularity?
> 
> D. Stimits, stimits@xxxxxxxxxx (currently bored)


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