On Sat, Mar 16, 2002 at 09:05:04PM +0100, Andi Kleen wrote:
> On Sat, Mar 16, 2002 at 12:57:11PM -0700, [email protected] wrote:
> > On Sat, Mar 16, 2002 at 08:32:26PM +0100, Andi Kleen wrote:
> > > x86-64 aka AMD Hammer does hardware (or more likely microcode) search of
> > > page tables.
> > > It has a 4 level page table with 4K pages. Generic Linux MM code only sees
> > > the first slot in 4th level page limit user space to 512GB with 3 levels.
> >
> > What about 2M pages?
>
> They are not supported for user space, but used in private mappings
> for kernel text and direct memory mappings. Generic code never sees them.
>
> That will hopefully change eventually because 2M pages are a bit help for
> a lot of applications that are limited by TLB thrashing, but needs some
> thinking on how to avoid the fragmentation trap (e.g. I'm considering
> to add a highmem zone again just for that and use rmap with targetted
> physical freeing to allocating them)
To me, once you have a G of memory, wasting a few meg on unused process
memory seems no big deal.
> > There was something in some AMD doc about preventing tlbflush on process
> > switch - through a context like thing perhaps? Any idea?
>
> There are global pages which are normally not flushed over context switch.
> That is used for all kernel mappings.
>
> There is also some optimization in the CPU that tries to do a selective
> flush only when you reload CR3, but as far as I can see doesn't help
> for the Linux context switch. It only works around broken TLB flushing
> algorithms in some Windows version.
They say:
Hammer microarchitecture features a flush filter allowing multiple
processes to share TLB without SW intervention.
Not a lot of technical detail in that.
>
> -Andi
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
http://www.fsmlabs.com http://www.rtlinux.com
[email protected] writes:
> On Sat, Mar 16, 2002 at 09:05:04PM +0100, Andi Kleen wrote:
> > That will hopefully change eventually because 2M pages are a bit help for
> > a lot of applications that are limited by TLB thrashing, but needs some
> > thinking on how to avoid the fragmentation trap (e.g. I'm considering
> > to add a highmem zone again just for that and use rmap with targetted
> > physical freeing to allocating them)
>
> To me, once you have a G of memory, wasting a few meg on unused
> process memory seems no big deal.
I'm not happy to throw away 2 MiB per process. My workstation has 1
GiB of RAM, and 65 processes (and that's fairly low compared to your
average desktop these days, because I just use olwm and don't have a
fancy desktop or lots of windows). You want me to throw over 1/8th of
my RAM away?!?
And in fact, isn't it going to be more than 2 MiB wasted per process?
For each shared object loaded, only partial pages are going to be
used. *My* libc is less than 700 KiB, so I'd be wasting most of a page
to map it in.
I want that 1 GiB of RAM to be used to cache most of my data. Those
NASA 1km/pixel satellite mosaics of the world are pretty big, you know
(21600x21600x3 per hemisphere:-).
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
On Sat, 16 Mar 2002 [email protected] wrote:
>
> To me, once you have a G of memory, wasting a few meg on unused process
> memory seems no big deal.
It's not the process memory, and it is a whole lot than a "few meg" if
your page size is 2M.
Look at "free" output one day, and notice that "cached" line? On my 2G
machine, I usually have about a gig cached or so. Guess what the most
common thing in that case is? Yeah, the kernel.
And my kernel tree (with bk overhead etc) is right not about 25.000 files.
That's without object files etc. At 2M a pop in the page cache, that's a
whole lot more memory for caching than I have in my machine.
Ok, so assume you compress that, and you only actually use the full 2M
when mapping into user space, you now added a lot of complexity, but at
least you make the ridiculous memory use go down.
But even in the process space, I've got about 150 processes quite
normally, and while most of them are idle, if we had 2M pages most of them
would waste at least 2M of memory (probably more - the stack doesn't even
need half a page, and the data section would probably waste half a page on
average).
That's 300M just wasted.
Tell me that's peanuts even if you've got a few gigs of ram on your
machine.
Admit it, you're just wrong. 2M page sizes are _not_ useful for the common
case, and won't be for years to come.
In short, you?re
> They say:
> Hammer microarchitecture features a flush filter allowing multiple
> processes to share TLB without SW intervention.
>
> Not a lot of technical detail in that.
I suspect it's some special case for windows with a special MSR that
enables something illegal that just works well for whatever patterns
windows does.
Linus
On Sat, Mar 16, 2002 at 12:34:29PM -0800, Linus Torvalds wrote:
>
> On Sat, 16 Mar 2002 [email protected] wrote:
> >
> > To me, once you have a G of memory, wasting a few meg on unused process
> > memory seems no big deal.
>
> It's not the process memory, and it is a whole lot than a "few meg" if
> your page size is 2M.
I forget what an extremist you are. My claim is that
some processes benefit from big pages, some do not.
A 16G process needs 2^25 bytes of PTE at 4kbytes/page if I
did the numbers right. Just populating 4 million odd page tables is a
pain. I might be wrong about it, but I wonder if just scaling
up from a working 32 bit strategy gets you anywhere.
If you want to optimize for gnome, you get a very different
layout. But Hammer and ia64 are supposedly designed for huge
databases, routing tables, and images. Our good friends at Intel
claim "carrier grade" Linux needs to run threaded apps
with 10,000 threads to depose Solaris in telecom - all sharing the
same monster address space.
> Admit it, you're just wrong. 2M page sizes are _not_ useful for the common
> case, and won't be for years to come.
What's the "common case" for 64 bit ? Do you really think it will
be on desktop soon?
>
> In short, you?re
Don't use umlauts unless you are ready to back it up.
>
> > They say:
> > Hammer microarchitecture features a flush filter allowing multiple
> > processes to share TLB without SW intervention.
> >
> > Not a lot of technical detail in that.
>
> I suspect it's some special case for windows with a special MSR that
> enables something illegal that just works well for whatever patterns
> windows does.
sounds like it from what Andi wrote. disappointing.
>
> Linus
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
http://www.fsmlabs.com http://www.rtlinux.com
> databases, routing tables, and images. Our good friends at Intel
> claim "carrier grade" Linux needs to run threaded apps
> with 10,000 threads to depose Solaris in telecom - all sharing the
> same monster address space.=20
Thats intel though. The same people who seem to think that hyperthreading
in the CPU is required for carrier grade work 8)
On Sat, 16 Mar 2002, Alan Cox wrote:
>
> Thats intel though. The same people who seem to think that hyperthreading
> in the CPU is required for carrier grade work 8)
Well, to be fair, they do seem to be making inroads against Sun.
Maybe that factor-of-five performance edge has something to do with that
part, though ;)
Linus
On Sat, 16 Mar 2002 [email protected] wrote:
>
> If you want to optimize for gnome, you get a very different
> layout. But Hammer and ia64 are supposedly designed for huge
> databases, routing tables, and images.
Yeah, and I'm claiming that databases etc count for a whole lot less than
most other apps.
> What's the "common case" for 64 bit ? Do you really think it will
> be on desktop soon?
Oh, not Itanium for sure. But if AMD succeeds even reasonably with Hammer,
Intel will certainly see the error of its ways (except they won't admit
it) and make their version of a 64-bit P4 core available. They're
reportedly working on it already, just in case the Itanic sinks (and
judging by current market behaviour it certainly isn't flying).
> > In short, you?re
>
> Don't use umlauts unless you are ready to back it up.
That's not an umlaut, that's an "?", which is a real letter in Finnish and
Swedish (it just _looks_ like an a with an umlaut to you uncultured
people), and it happens to be a letter that is just left of the ' mark on
a Finnish keyboard.
Linus
On Sat, Mar 16, 2002 at 10:00:07PM +0000, Alan Cox wrote:
> > databases, routing tables, and images. Our good friends at Intel
> > claim "carrier grade" Linux needs to run threaded apps
> > with 10,000 threads to depose Solaris in telecom - all sharing the
> > same monster address space.=20
>
> Thats intel though. The same people who seem to think that hyperthreading
> in the CPU is required for carrier grade work 8)
I love the whole sound of "carrier grade" though: Do you use "carrier grade"
Linux or just the "recreational boating" version?
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
http://www.fsmlabs.com http://www.rtlinux.com
On Sat, 16 Mar 2002 [email protected] wrote:
| On Sat, Mar 16, 2002 at 10:00:07PM +0000, Alan Cox wrote:
| > > databases, routing tables, and images. Our good friends at Intel
| > > claim "carrier grade" Linux needs to run threaded apps
| > > with 10,000 threads to depose Solaris in telecom - all sharing the
| > > same monster address space.=20
| >
| > Thats intel though. The same people who seem to think that hyperthreading
| > in the CPU is required for carrier grade work 8)
|
| I love the whole sound of "carrier grade" though: Do you use "carrier grade"
| Linux or just the "recreational boating" version?
Don't know what Intel is claiming, but OSDL is
sponsoring a "Carrier Grade Linux Working Group".
See info at http://www.osdl.org and/or at cglinux.sf.net .
--
~Randy
> I love the whole sound of "carrier grade" though: Do you use "carrier grade"
> Linux or just the "recreational boating" version?
Linux is alread carrier (pigeon) grade
-> http://www.blug.linux.no/rfc1149/
[email protected] (Linus Torvalds) wrote on 16.03.02 in <[email protected]>:
> On Sat, 16 Mar 2002 [email protected] wrote:
> > > In short, youaere
> >
> > Don't use umlauts unless you are ready to back it up.
>
> That's not an umlaut, that's an "ae", which is a real letter in Finnish and
> Swedish (it just _looks_ like an a with an umlaut to you uncultured
> people), and it happens to be a letter that is just left of the ' mark on
> a Finnish keyboard.
Hey, careful there! Those English speakers stole that name from German,
and in German those umlauts are real letters, too. Incidentally, my ae is
next to the '# key ...
MfG Kai
[email protected] wrote on 16.03.02 in <[email protected]>:
> On Sat, Mar 16, 2002 at 10:00:07PM +0000, Alan Cox wrote:
> > > databases, routing tables, and images. Our good friends at Intel
> > > claim "carrier grade" Linux needs to run threaded apps
> > > with 10,000 threads to depose Solaris in telecom - all sharing the
> > > same monster address space.=20
> >
> > Thats intel though. The same people who seem to think that hyperthreading
> > in the CPU is required for carrier grade work 8)
>
> I love the whole sound of "carrier grade" though: Do you use "carrier grade"
> Linux or just the "recreational boating" version?
Wrong carrier, though. It's not US Navy carriers (those people use NT,
after all, and this was "depose Solaris"), it's carriers like AT&T - phone
companies. And I suspect many of those 10,000 threads are handling one
phone conversation each. Or maybe one half of one.
In fact, that's a problem space I find much more interesting than the
military. *These* people need to be robust in peacetime. They can't afford
a big showy piece of hardware that breaks down when it's finally needed,
because "finally" is a very short-term goal.
MfG Kai
> > That's not an umlaut, that's an "ae", which is a real letter in Finnish and
> > Swedish (it just _looks_ like an a with an umlaut to you uncultured
> > people), and it happens to be a letter that is just left of the ' mark on
> > a Finnish keyboard.
>
> Hey, careful there! Those English speakers stole that name from German,
> and in German those umlauts are real letters, too. Incidentally, my ae is
> next to the '# key ...
There are still a couple of places you can legitimaely use an ae symbol in
English. It's not quite dead yet 8)
You might want to upgrade to the newer one, the patch has undergone a lot
of changes and -ac against the XFS merge of the quotactl patch seriously
breaks ;-(
Shawn.
On Sun, Mar 17, 2002 at 04:52:00PM +0200, Kai Henningsen wrote:
> [email protected] wrote on 16.03.02 in <[email protected]>:
>
> > On Sat, Mar 16, 2002 at 10:00:07PM +0000, Alan Cox wrote:
> > > > databases, routing tables, and images. Our good friends at Intel
> > > > claim "carrier grade" Linux needs to run threaded apps
> > > > with 10,000 threads to depose Solaris in telecom - all sharing the
> > > > same monster address space.=20
> > >
> > > Thats intel though. The same people who seem to think that hyperthreading
> > > in the CPU is required for carrier grade work 8)
> >
> > I love the whole sound of "carrier grade" though: Do you use "carrier grade"
> > Linux or just the "recreational boating" version?
>
> Wrong carrier, though. It's not US Navy carriers (those people use NT,
> after all, and this was "depose Solaris"), it's carriers like AT&T - phone
Really? So why are they always talking about that ship SS7 and the
sonar network - SONET ? I think Alan may have something there about the
carrier pigeon angle, though. Needs more study.
Actually, it makes me think of "as big, manoeuverable, and
low cost as an aircraft carrier" although that is certainly unfair.
> companies. And I suspect many of those 10,000 threads are handling one
> phone conversation each. Or maybe one half of one.
>
> In fact, that's a problem space I find much more interesting than the
> military. *These* people need to be robust in peacetime. They can't afford
> a big showy piece of hardware that breaks down when it's finally needed,
> because "finally" is a very short-term goal.
But in my, as always ever so humble, opinion, 10,000 threads is a programming
error based on the incorrect Solaris theory that threads were a good
substitute for thinking about scheduling operations. So making Linux
handle 10K threads is not necessarily an appealing idea unless you can
think of some very clever way to do it.
On the other hand, if I just wanted to sell chips, I might think
differently.
>
> MfG Kai
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
http://www.fsmlabs.com http://www.rtlinux.com
> You might want to upgrade to the newer one, the patch has undergone a lot
> of changes and -ac against the XFS merge of the quotactl patch seriously
> breaks ;-(
The -ac patch is the current stable 2.4 one for 32bit uid quota. XFS is
a 2.5 problem so for the moment I'm not remotely bothered by it
Right, but which old patch 2.4.18-pre3-quotactl reversed against
2.4.19-pre3-ac1 doesnt go out cleanly without patch complaining about
unreversed patch problems.
Shawn.
On Mon, 18 Mar 2002, Nathan Scott wrote:
> On Sun, 17 Mar 2002, Alan Cox wrote:
> > >
> > > You might want to upgrade to the newer one, the patch has undergone a lot
> > > of changes and -ac against the XFS merge of the quotactl patch seriously
> > > breaks ;-(
> >
> > The -ac patch is the current stable 2.4 one for 32bit uid quota. [...]
> >
>
> Shawn,
>
> We are using Jan's latest "alpha" patches in XFS CVS (not the latest
> "stable" patches), so you will need to follow the recipe I sent out
> earlier (see below) for getting these patches to work together with
> the quota patch in Alan's patches. Following this recipe, nothing
> should "seriously break" -- please let me know if it does -- and no
> additional quota patches are necessary for XFS.
>
> cheers.
>
> --
> Nathan
>
>
> On Tue, Mar 05, 2002 at 12:59:04AM -0500, Shawn Starr wrote:
> >
> > I will be doing this today for -shawn10. Thank you.
> >
> > Shawn.
> >
> > On Tue, 5 Mar 2002, Nathan Scott wrote:
> > > Subject: TAKE - Even newer VFS quota
> > >
> > > This is Jan's latest set of VFS quota patches. These patches (which
> > > were posted to LKML on the weekend) allow the two VFS quota formats
> > > and quotactl interfaces to coexist. All seems stable on my machine.
> > >
> > > If you're one of the people merging XFS with Alan Cox's patches, you
> > > should first reverse-apply Jan's old patches (which removes the old
> > > 32 bit UID/GID quota from Alan's patches, and then apply the new code
> > > from the XFS CVS tree (which "re-applies" the 32 bit UID/GID quota
> > > patches, but now using Jan's new mechanisms).
> > >
> > > Please let us know of any quota oddities you see in the CVS tree.
> > >
> > > cheers.
> > >
>
>
> Right, but which old patch 2.4.18-pre3-quotactl reversed against
> 2.4.19-pre3-ac1 doesnt go out cleanly without patch complaining about
> unreversed patch problems.
It isnt a single patch, its patches with further fixes on top.
Shawn Starr wrote:
> > Right, but which old patch 2.4.18-pre3-quotactl reversed against
I assume you mean "2.4.18-pre3-ac2-quotactl.patch" from XFS CVS...
this was an incremental patch against Alan's tree, as described in
cmd/xfsmisc/README in the XFS CVS tree - it's not the right one to
be using here, since we're trying to back out the quota changes in
Alan's patches (a.k.a. Jan Kara's 32 bit uid/gid quota patches, at
ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/v2.4/)
> > 2.4.19-pre3-ac1 doesnt go out cleanly without patch complaining about
> > unreversed patch problems.
You would need to use the quota patch which is part of Alan's patches
in order to get back to the base kernel quota, before applying Jan's
new patches (which are patches against Linus'/Marcelo's kernels).
Alan Cox wrote:
> It isnt a single patch, its patches with further fixes on top.
So, I'm starting to think the patch you need doesn't exist, Shawn...
Previously I thought Alan simply used Jan's quota patches directly,
but from what Alan's saying it sounds like that isn't correct and he
has additional fixes which aren't in Jan's patches. (?)
Anyway, I imagine you would still get most of the way there by reverse
applying Jan's patch (quota-patch-2.4.17-3.diff in XFS CVS) and then
fixing up any remaining issues by hand. You just need to get back to
the base kernel quota as a starting point, because that's what Jan's
"alpha" patches are against (we use these in the XFS CVS tree now).
cheers.
--
Nathan
Hi!
> > > To me, once you have a G of memory, wasting a few meg on unused process
> > > memory seems no big deal.
> >
> > It's not the process memory, and it is a whole lot than a "few meg" if
> > your page size is 2M.
>
> I forget what an extremist you are. My claim is that
> some processes benefit from big pages, some do not.
> A 16G process needs 2^25 bytes of PTE at 4kbytes/page if I
> did the numbers right. Just populating 4 million odd page tables is a
> pain. I might be wrong about it, but I wonder if just scaling
> up from a working 32 bit strategy gets you anywhere.
> If you want to optimize for gnome, you get a very different
> layout. But Hammer and ia64 are supposedly designed for huge
> databases, routing tables, and images. Our good friends at Intel
Hammer is designed for desktop, AFAICT. [Its slightly modified athlon,
you see?]
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
On Tue, Mar 19, 2002 at 01:06:19PM +0100, Pavel Machek wrote:
> Hammer is designed for desktop, AFAICT. [Its slightly modified athlon,
> you see?]
Thanks for the insight. Only by reading LKM could
I have found out that AMD doesn't care about server space.
[email protected] wrote:
>
> On Tue, Mar 19, 2002 at 01:06:19PM +0100, Pavel Machek wrote:
> > Hammer is designed for desktop, AFAICT. [Its slightly modified athlon,
> > you see?]
>
> Thanks for the insight. Only by reading LKM could
> I have found out that AMD doesn't care about server space.
The sledgehammer is a bit more than a slightly modified athlon...
up to 8 way multiprocessing
64-bit addressing
hypertransport
integrated DDR memory controller
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
On Tue, Mar 19, 2002 at 05:09:37PM -0500, Chris Friesen wrote:
> [email protected] wrote:
> >
> > On Tue, Mar 19, 2002 at 01:06:19PM +0100, Pavel Machek wrote:
> > > Hammer is designed for desktop, AFAICT. [Its slightly modified athlon,
> > > you see?]
> >
> > Thanks for the insight. Only by reading LKM could
> > I have found out that AMD doesn't care about server space.
>
> The sledgehammer is a bit more than a slightly modified athlon...
>
> up to 8 way multiprocessing
> 64-bit addressing
> hypertransport
> integrated DDR memory controller
Look at http://www.amd.com front page for some subtle hints on where
the margin is.
>
>
> --
> Chris Friesen | MailStop: 043/33/F10
> Nortel Networks | work: (613) 765-0557
> 3500 Carling Avenue | fax: (613) 765-2986
> Nepean, ON K2H 8E9 Canada | email: [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
http://www.fsmlabs.com http://www.rtlinux.com
On Tue, 19 Mar 2002 [email protected] wrote:
> On Tue, Mar 19, 2002 at 01:06:19PM +0100, Pavel Machek wrote:
> > Hammer is designed for desktop, AFAICT. [Its slightly modified athlon,
> > you see?]
>
> Thanks for the insight. Only by reading LKM could
> I have found out that AMD doesn't care about server space.
You can get BS from Intel lovers in the Intel group as well. If you
believe that 8-way SMP doesn't indicate an interest in server space you
see a larger market for games and DSI than I do.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Mon, Mar 18, 2002 at 03:30:32AM +0200, Itai Nahshon wrote:
>
> > There are still a couple of places you can legitimaely use an ae symbol in
> > English. It's not quite dead yet 8)
>
> The only example that I've seen in English texts is use of ? as in "na?ve".
>
The two I can recall off the top of my head are "d?mon" and "f?rie".
DF
On Thu, Mar 21, 2002 at 12:38:13AM +0000, Derek Fawcus wrote:
> On Mon, Mar 18, 2002 at 03:30:32AM +0200, Itai Nahshon wrote:
> >
> > > There are still a couple of places you can legitimaely use an ae symbol in
> > > English. It's not quite dead yet 8)
> >
> > The only example that I've seen in English texts is use of ? as in "na?ve".
> >
>
> The two I can recall off the top of my head are "d?mon" and "f?rie".
And, of course, encyclop?dia. Or p?diatrician. Perhaps L?nux?
--
Tim Coleman <[email protected]> [43.28 N 80.31 W]
BMath, Honours Combinatorics and Optimization, University of Waterloo
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- Benjamin Franklin
> > Hey, careful there! Those English speakers stole that name from German,
> > and in German those umlauts are real letters, too. Incidentally, my ae is
> > next to the '# key ...
There are many ways to count "real" letters. Eg., Hebrew (my
native lang.) counts just 22 but there are 27 glyphs and many
combinations with points (Nikkud) and accents. The Spanish count
27 letters in their alphabet (? is a real letter) while the Brazilians
count only 23 (the 26 English letters minus K,W and Y). Some
east-Asian languages haven't finished the count yet (or never
have started)...
> There are still a couple of places you can legitimaely use an ae symbol in
> English. It's not quite dead yet 8)
The only example that I've seen in English texts is use of ? as in "na?ve".
I know that ? is used in German and in other languages but if I see
a text that contains a double-? or 3 ? in one word that's almost certainly
Finnish...
-- Itai
oh ok.
Thanks.
On Sun, 17 Mar 2002, Alan Cox wrote:
> > You might want to upgrade to the newer one, the patch has undergone a lot
> > of changes and -ac against the XFS merge of the quotactl patch seriously
> > breaks ;-(
>
> The -ac patch is the current stable 2.4 one for 32bit uid quota. XFS is
> a 2.5 problem so for the moment I'm not remotely bothered by it
>
>
>
On Sun, 17 Mar 2002, Alan Cox wrote:
> >
> > You might want to upgrade to the newer one, the patch has undergone a lot
> > of changes and -ac against the XFS merge of the quotactl patch seriously
> > breaks ;-(
>
> The -ac patch is the current stable 2.4 one for 32bit uid quota. [...]
>
Shawn,
We are using Jan's latest "alpha" patches in XFS CVS (not the latest
"stable" patches), so you will need to follow the recipe I sent out
earlier (see below) for getting these patches to work together with
the quota patch in Alan's patches. Following this recipe, nothing
should "seriously break" -- please let me know if it does -- and no
additional quota patches are necessary for XFS.
cheers.
--
Nathan
On Tue, Mar 05, 2002 at 12:59:04AM -0500, Shawn Starr wrote:
>
> I will be doing this today for -shawn10. Thank you.
>
> Shawn.
>
> On Tue, 5 Mar 2002, Nathan Scott wrote:
> > Subject: TAKE - Even newer VFS quota
> >
> > This is Jan's latest set of VFS quota patches. These patches (which
> > were posted to LKML on the weekend) allow the two VFS quota formats
> > and quotactl interfaces to coexist. All seems stable on my machine.
> >
> > If you're one of the people merging XFS with Alan Cox's patches, you
> > should first reverse-apply Jan's old patches (which removes the old
> > 32 bit UID/GID quota from Alan's patches, and then apply the new code
> > from the XFS CVS tree (which "re-applies" the 32 bit UID/GID quota
> > patches, but now using Jan's new mechanisms).
> >
> > Please let us know of any quota oddities you see in the CVS tree.
> >
> > cheers.
> >