On Fri, Oct 12, 2001 at 11:33:07AM +1100, Nathan Scott wrote:
> > When switching off only XFS quotas it works! Seems to be nailed down:
> Uhrm. Well, thats very odd.
> Let me see if we're on the same page - you have a system with no XFS
> filesystems, and no filesystems of any type with any form of quota
> at all. And then you dd one >2Gb partition to another, same size.
> This fails with CONFIG_XFS_QUOTA set, but works without it. It works
> also before 2.4.10, independent of any quota config options.
> Your failure is seen in dd(1), copying at the 2Gb mark, it prints out
> something like "File size limit exceeded" (ie. it receives a SIGXFSZ
> signal), and exits.
> Is that all correct?
Yes. It receives a SIGXFSZ.
> - There is no possibility that any XFS quota code is being exectued
> in your setup (no XFS code at all), other than at bootup - where we
> don't do much, mainly just some global initialization (locks, memory
> allocation, etc) - so, I'm a bit amazed that switching off XFS quota
> can change the outcome at all here;
There is no XFS filesystem active at that point of time.
> - I'm not sure how even the VFS quota can be involved here, since
> that quota code should only come into play for a filesystem where we
> have quota enabled;
> - SIGXFSZ has nothing to do with filesystem quota, it is sent to a
> process from truncate/write when the file offset reaches certain
> limits (in contrast, quota being exceeded would fail the write with
> errno set to EDQUOT, not by sending a signal).
I know. I have looked into the kernel code from where the SIGXFSZ
is produced, and there is even an if that handles block devices
so that writing to them should never be interrupted by SIGXFSZ.
(If I read the code correct, that is ;-)
> Do you see any system console messages when you get the error?
I will try your latest CVS code today and give reports.
Computer Scientist Epigenomics AG
Bioinformatics R&D www.epigenomics.com Kastanienallee 24
+493024345330 10435 Berlin