On Nov 19, 2001 18:28 +0100, Rogier Wolff wrote:
> > There is another report saying 2.4.14
> > also "Creating partitions under 2.4.14", and I have read several more
> > recently but am unsure of the exact kernel version. What fs are you
> > using, just in case it matters?
>
> ext2.
Well, I just tried this on ext2 instead of ext3 (on my 2.4.13 system)
and it worked fine as a logged-in non-root user (creates a 16GB sparse file):
dd if=/dev/zero of=tt bs=1k count=1 seek=16M
> > I know for sure that 2.4.13+ext3 is working mostly OK, as I have been
> > playing with multi-TB file sizes (sparse of course) although there is
> > a minor bug in the case where you hit the fs size maximum. I'm glad
> > my patch isn't in yet, or I would be getting flak over this I'm sure.
>
> > The only problem is that I can't see anything in the 2.4.14 patch which
> > would cause this problem. All the previous reports had to do with
> > ulimit, caused by su'ing to root instead of logging into root, but I'm
> > not sure exactly where the problem lies.
>
> Gotcha!!!!
>
> The "wouldn't work" case was tested by me, logged in as wolff, su-ing
> to root, and the "works just fine" cases were tested by a guy who logs
> in to the machine on the console (as root).
>
>
> Now, can someone tell me why "unlimited" is interpreted somehow as 2G
> or something thereabouts? :
>
> /home/wolff> limit
> cputime unlimited
> filesize unlimited
> datasize unlimited
> stacksize unlimited
> coredumpsize unlimited
> memoryuse unlimited
> descriptors 1024
> memorylocked unlimited
> maxproc 4095
> openfiles 1024
> /home/wolff> su
> Password:
> /home/wolff# limit
> cputime unlimited
> filesize unlimited
> datasize unlimited
> stacksize unlimited
> coredumpsize unlimited
> memoryuse unlimited
> descriptors 1024
> memorylocked unlimited
> maxproc 4095
> openfiles 1024
Well, because of 32-bit API issues "unlimited" actually IS the same as 2G
for 32-bit systems, but the code internally checks if the limit is equal
to RLIM_INFINITY (mm/filemap.c:generic_file_write()) and (should) ignore
it if so. Thus it is impossible to set a ulimit exactly 2GB, but that
isn't really a problem.
Hmm, looking at the user-space header <customs/customs.h>, it has
RLIM_INFINITY as 0x7fffffff, the <bits/resource.h> has:
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int) (~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif
but the kernel code has RLIM_INFINITY as ~0UL for most arches.
> /home/wolff# cat /proc/version
> Linux version 2.4.9 (wolff@machine) (gcc version 2.95.2 19991024 (release)) #3 SMP
> Mon Sep 10 09:17:17 BST 2001
> /home/wolff#
>
> (The machine was downgraded due to other problems. )
Can you test the "dd" above to ensure it works with your tools and the old
kernel? For your next 2.4.14 kernel build, it may be instructive to put
a printk() inside the 3 checks in generic_file_write() before it outputs
SIGXFSZ, which tells us limit and RLIM_INIFINITY, pos and count, and pos
and s_maxbytes are, respectively. This will also tell us what limit is
being hit (although it is most likely a ulimit issue).
Cheers, Andreas
-- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Nov 23 2001 - 21:00:21 EST