* Re: DNAT based on domain name instead of IP address
From: Shawn @ 2004-01-29 0:02 UTC (permalink / raw)
To: Erik Bourget; +Cc: Glen Lee Edwards, netfilter@lists.netfilter.org
In-Reply-To: <87llnr1vqq.fsf@loki.odinnet>
Yeah, only he does not have any "one true apache" server answering. I
thnik that is, however, what he /should/ do.
On Wed, 2004-01-28 at 17:47, Erik Bourget wrote:
> Glen Lee Edwards <glen@holiness.ch> writes:
>
> > I have several domains that use the same IP address. Can I DNAT them to
> > different servers based on domain name instead of IP address using
> > iptables? I've tried the following, but it isn't working:
> >
> > iptables -t nat -A PREROUTING -p tcp -d 1st.domain.com --dport 80 -j
> > DNAT --to-destination 192.168.1.12:80
> >
> > iptables -t nat -A PREROUTING -p tcp -d 2nd.domain.com --dport 80 -j
> > DNAT --to-destination 192.168.1.13:80
> >
> > Everything is being forwarded to 192.168.1.12 no matter which domain is
> > used. It appears that the domains are first being translated into the
> > IP address, which is used instead.
>
> TCP packets know nothing of DNS ... an application will 1) look up the name at
> a DNS server, 2) retrieve the IP from the DNS server, and 3) connect to the IP
> address.
>
> Apache can do virtual domains ... HTTP 1.1 requires that you specify the
> domain name.
>
> - Erik
>
>
^ permalink raw reply
* Re: [PATCH 2.6] netfilter /proc/net/ip_conntrack locking fix
From: David S. Miller @ 2004-01-29 0:01 UTC (permalink / raw)
To: Harald Welte; +Cc: netfilter-devel
In-Reply-To: <20040127214559.GD11761@sunbeam.de.gnumonks.org>
On Tue, 27 Jan 2004 22:45:59 +0100
Harald Welte <laforge@netfilter.org> wrote:
> Please apply the following fix to your 2.6.x tree.
>
> Name: Grab ip_conntrack_expect_tuple_lock in list_conntracks
> Author: Rusty Russell
> Status: Experimental
Applied, thanks.
But please in the future, when providing patch authors give me an
email address to use. Luckily I know Rusty's so this one I could
handle :)
^ permalink raw reply
* Re: DNAT based on domain name instead of IP address
From: Shawn @ 2004-01-29 0:01 UTC (permalink / raw)
To: John A. Sullivan III; +Cc: Glen Lee Edwards, netfilter@lists.netfilter.org
In-Reply-To: <1075333547.1902.34.camel@jasiiitosh.nexusmgmt.com>
Doesn't apache have the smarts to figure it out on its own? I've never
put squid in as an incomming request proxy server. I don't know that
squid or apache will give you quite what you want though.
1st, determine if you /really/ need two servers (.12 and .13). I think a
single apache can have multiple document roots based on the domain in
the URL requested.
2nd, if you do think you need 2 servers, figure out why exactly and if
you can solve the problem from some other angle.
3rd, if you really need it, I think L7 filtering is how you want to go,
but I can't guide you. I've not yet found a problem to solve with L7 for
myself.
On Wed, 2004-01-28 at 17:45, John A. Sullivan III wrote:
> On Wed, 2004-01-28 at 18:22, Glen Lee Edwards wrote:
> > I have several domains that use the same IP address. Can I DNAT them to
> > different servers based on domain name instead of IP address using
> > iptables? I've tried the following, but it isn't working:
> >
> > iptables -t nat -A PREROUTING -p tcp -d 1st.domain.com --dport 80 -j
> > DNAT --to-destination 192.168.1.12:80
> >
> > iptables -t nat -A PREROUTING -p tcp -d 2nd.domain.com --dport 80 -j
> > DNAT --to-destination 192.168.1.13:80
> >
> > Everything is being forwarded to 192.168.1.12 no matter which domain is
> > used. It appears that the domains are first being translated into the
> > IP address, which is used instead.
> >
> > Glen
>
> I'm going to go way out on a limb here and speculate so if someone who
> has actually looked at the code tells you otherwise, please listen to
> them and not me!
>
> I would assume that netfilter is only operating at layer 3. I believe
> from an earlier enlightening post from Anthony Stone(?) that all domain
> names are resolved to IP addresses when the rule is loaded and the rule
> uses the layer three information, i.e., the IP address, to evaluate the
> rule.
>
> It sounds like you need something that will operate on the layer 7 data
> since that's where the url/uri information is going to be. Perhaps a
> proxy like squid has the ability to redirect traffic based upon layer 7
> information.
>
> I'm quite curious to see how you ultimately resolve this. Good luck -
> John
^ permalink raw reply
* Re: [PATCH] netfilter cosmetic: add/correct copyright notices
From: David S. Miller @ 2004-01-28 23:59 UTC (permalink / raw)
To: Harald Welte; +Cc: netfilter-devel
In-Reply-To: <20040127214247.GC11761@sunbeam.de.gnumonks.org>
On Tue, 27 Jan 2004 22:42:47 +0100
Harald Welte <laforge@netfilter.org> wrote:
> The attached patch adds and/or corrects copyright notices and GPL
> statements throughout the netfilter code.
>
> It applies cleanly to 2.6.2-rc2.
>
> Please apply, thanks.
Applied, thanks Harald.
^ permalink raw reply
* Boot code stack size
From: Greg Watson @ 2004-01-28 23:59 UTC (permalink / raw)
To: linuxppc-dev
I'm working on the PPC LinuxBIOS project and have recently managed to
boot the Sandpoint (Altimus 7410 PMC) using the latest
linuxppc_2_4_devel kernel (2.4.24-pre2).
However while getting Linux to run on this machine, I hit a problem
with this and earlier kernels running out of stack while
uncompressing the kernel image. The symptom I see is that inflate
returns -3 (FFFFFFFD). To get around the problem, I have to modify
arch/ppc/boot/common/relocate.S and increase the stack size from 8K
(4096*2) to 28K (4096*7). The kernel image is 792890 bytes compressed
and 1734312 bytes uncompressed. The Sandpoint boots reliably with the
increased stack size.
I'm wondering a) if anyone has seen this problem while booting other
PPC based systems, and b) if it would be worth adding a configuration
option that allows this early stack size to be specified, rather than
hard-coding it in relocate.S.
Regards,
Greg
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: DNAT based on domain name instead of IP address
From: William Stearns @ 2004-01-28 23:59 UTC (permalink / raw)
To: Glen Lee Edwards; +Cc: ML-netfilter, William Stearns
In-Reply-To: <1075332153.25415.98.camel@child-of-god.holiness.ch>
Good evening, Glen,
On 28 Jan 2004, Glen Lee Edwards wrote:
> I have several domains that use the same IP address. Can I DNAT them to
> different servers based on domain name instead of IP address using
> iptables? I've tried the following, but it isn't working:
>
> iptables -t nat -A PREROUTING -p tcp -d 1st.domain.com --dport 80 -j
> DNAT --to-destination 192.168.1.12:80
>
> iptables -t nat -A PREROUTING -p tcp -d 2nd.domain.com --dport 80 -j
> DNAT --to-destination 192.168.1.13:80
>
> Everything is being forwarded to 192.168.1.12 no matter which domain is
> used. It appears that the domains are first being translated into the
> IP address, which is used instead.
You're last statement explains what's happening, and you're
exactly right. Even if you use domain names on the command line, iptables
converts them to ip addresses before handing them off to the kernel.
Iptables isn't really capable of what you're asking; it's
primarily designed to make choices about packets based on header
information. Although some components of it can inspect the payload, it's
not capable of doing the differentiation you need.
What you want is a userspace application that can look in the
payload of the packet and identify the Host: header in an http request,
and send the connection off to the right web server based on that header.
One place to start is the squid cache (
http://www.squid-cache.org ) and the httpd_accel_* options.
Cheers,
- Bill
---------------------------------------------------------------------------
"We don't want an election without a paper trail...all three
owners of the companies who make these machines are donors to the Bush
administration. Is this not corruption?"
-- Gore Vidal
(Courtesy of http://www.laweekly.com/ink/03/52/features-cooper.php)
--------------------------------------------------------------------------
William Stearns (wstearns@pobox.com). Mason, Buildkernel, freedups, p0f,
rsync-backup, ssh-keyinstall, dns-check, more at: http://www.stearns.org
--------------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] - Improve SN2 TLB flushing algorithms
From: Peter Chubb @ 2004-01-28 23:57 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <20040128205912.GA27401@sgi.com>
>>>>> "Jack" = Jack Steiner <steiner@SGI.com> writes:
Jack> On Wed, Jan 28, 2004 at 09:17:59PM +0000, Christoph Hellwig
Jack> wrote:
>> On Wed, Jan 28, 2004 at 02:59:12PM -0600, Jack Steiner wrote: >
>> +#ifdef CONFIG_NUMA > + cpus_clear(mm->cpu_vm_mask); > +#endif
>>
>> I really hate this ifdefs all over the place. Does this really
>> hurt that much on non-NUMA systems? Also SN2 seems to use this
>> code always so CONFIG_NUMA looks like the wrong ifdef to me.
Jack> Are you suggesting that we remove the #ifdef OR hide the code in
Jack> a function that, depending on config options, may or may not do
Jack> anything?
Jack> The code is needed on kernels built for SN2. That includes both
Jack> CONFIG_IA64_GENERIC & CONFIG_IA64_SGI_SN2. I agree that
Jack> CONFIG_NUMA is not a great choice but nothing else seemed
Jack> appropriate.
As CONFIG_IA64_GENERIC is a superset of CONFIG_IA64_SGI_SN2
why not make CONFIG_IA64_GENERIC turn on CONFIG_IA64_SGI_SN2 and
then only test for the latter.
And yes, using a function that disappears or does nothing on platforms
for which it is inappropriate is a better approach than littering
#ifdefs though the code.
--
Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au
The technical we do immediately, the political takes *forever*
^ permalink raw reply
* Re: [PATCH] cpqarray update
From: Greg KH @ 2004-01-28 23:51 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Hollis Blanchard, Linux Kernel Mailing List, francis.wiran
In-Reply-To: <40184960.7030207@pobox.com>
On Wed, Jan 28, 2004 at 06:44:32PM -0500, Jeff Garzik wrote:
> Jeff Garzik wrote:
> >Actually I disagree with GregKH on this.
> >
> >The register/unregister functions need to be returning error codes,
> >_not_ the count of interfaces registered. It is trivial to count the
> >registered interfaces in the driver itself, but IMO far more important
> >to propagate fatal errors back to the original caller.
>
> Nevermind, this got fixed. I'm still worried about the '1' return
> value, though, for zero controllers found.
Yeah, I don't really like it either, but figured it was a 2.7 task to
clean it up properly.
thanks,
greg k-h
^ permalink raw reply
* Re: [2.0.40-rc8] Works well
From: David Weinehall @ 2004-01-28 23:50 UTC (permalink / raw)
To: Markus Hästbacka; +Cc: Kernel Mailinglist
In-Reply-To: <Pine.LNX.4.44.0401290135070.29405-100000@midi>
On Thu, Jan 29, 2004 at 01:37:37AM +0200, Markus Hästbacka wrote:
> Btw - Are you going to announce the release of 2.0.40 (whenever it's
> coming) or just put it on kernel.org?
I will announce it. It won't have any differences from 2.0.40-rc8
though (unless someone uncovers a flaw in -rc8 of course, which would
cause me to release an -rc9.)
Regards: David Weinehall
--
/) David Weinehall <tao@acc.umu.se> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
^ permalink raw reply
* Re: PROBLEM: ACPI crashes (2.6.2-rc2-mm1)
From: Greg Sarjeant @ 2004-01-28 23:48 UTC (permalink / raw)
To: Luca Capello; +Cc: ML ACPI-devel
In-Reply-To: <40182D90.8090102-wlebWZzHoyE@public.gmane.org>
Hi,
Just wanted to add my experience. I was able to suspend to disk and
resume just fine from a console with the following configuration on the
Gateway 200X.
kernel 2.6.1
agpgart module loaded
intel_agp module loaded
i830 module loaded
swsusp compiled into the kernel
ACPI sleep states compiled into the kernel
suspend with 'echo 4 > /proc/acpi/sleep'
When I tried this after starting X with startx, I got the reboot loop
described by others. I figured I'd give it a shot, since the AGP modules
didn't interfere with the console suspend/resume. Ah well.
Interestingly, starting X and then dropping back into a console
caused problems, too. I didn't get stuck in a reboot loop, but the
resume just hung. It did get past the 'Waiting for DMA to settle down'
message, though. I can't remember now exactly what it said, but it
seemed to be mostly done. I had to do a hard reboot to get it back, and
then I had to do the 'noresume; mkswap; swapon' routine.
I haven't tried unaccelerated X, since the AGP modules seem to be
loaded regardless of what I do (remove the agpgart alias in
/etc/modules.conf, remove X from default runlevel, etc) and I cannot
unload them. I guess I should try compiling a kernel without AGP support
at all next.
Thanks,
Greg
On Wed, 2004-01-28 at 16:45, Luca Capello wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> on 01/28/04 21:18, Jonas Petersson wrote:
> > For the record: Several of us over on the swsusp list appear to have
> > rouchly the same problem: With some effort and fiddling (as described in
> > the previous mail), swsusp2 works for console and even from
> > unaccelerated X, but whenever DRI ang AGP is enabled it resume will
> > crash. [...]
> just for the record, in my case, 'swsusp' (normal, not the 'swsusp2' by
> Nigel Cunningham) works *perfectly* without DRI and AGP. 'Perfectly'
> means that I can suspend from X (obviously, unaccelerated) and
> successfully resume on X with the USB and ALSA (0.9.7) modules loaded
> (but as I don't have any USB devices here, I can't tell if USB working
> let you suspend/resume). This is a starting point, I hope, even for the
> 'swsusp' mode.
>
> I never tried 'swsusp2', I could give it a try if necessary. The same
> for 'pmdisk'.
>
> > [...] Some of us think this is related to the agpgart rewrite for
> > 2.6.x, but our patching so far have not made any difference. There seem
> > to be resume code in the intel-agp plug which we have tried to duplicate
> > in sis-agp, but it appears not to be called during resume...
> Well, I could try on 2.4.23 to find out if the problem is 2.6 or not.
> Anyway, what is strange is that the problem is on an Intel graphics
> chipset, so it the 'intel-agp' has some resume code, it /should/ work.
> And this isn't the case :-(
>
> Thx, bye,
> Gismo / Luca
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> Comment: Using GnuPG with Debian - http://enigmail.mozdev.org
>
> iD8DBQFAGC2PVAp7Xm10JmkRAtzkAJ0av0/zp68P5bNNI/G/WasPpVMoRgCfYR8z
> 2dan6DRA9q1gqVAbRs+VyGE=
> =R2Yz
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
>
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: NetBSD port and a couple of remarks
From: Kip Macy @ 2004-01-28 23:48 UTC (permalink / raw)
To: Andi Kleen; +Cc: Ian.Pratt, xen-devel, lm
In-Reply-To: <20040129002422.099b7d14.ak@suse.de>
=> whoever owns BitKeeper at some point won't sue you,
In light of recent events that is a genuinely compelling point.
-Kip
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: DNAT based on domain name instead of IP address
From: Erik Bourget @ 2004-01-28 23:47 UTC (permalink / raw)
To: Glen Lee Edwards; +Cc: netfilter
In-Reply-To: <1075332153.25415.98.camel@child-of-god.holiness.ch>
Glen Lee Edwards <glen@holiness.ch> writes:
> I have several domains that use the same IP address. Can I DNAT them to
> different servers based on domain name instead of IP address using
> iptables? I've tried the following, but it isn't working:
>
> iptables -t nat -A PREROUTING -p tcp -d 1st.domain.com --dport 80 -j
> DNAT --to-destination 192.168.1.12:80
>
> iptables -t nat -A PREROUTING -p tcp -d 2nd.domain.com --dport 80 -j
> DNAT --to-destination 192.168.1.13:80
>
> Everything is being forwarded to 192.168.1.12 no matter which domain is
> used. It appears that the domains are first being translated into the
> IP address, which is used instead.
TCP packets know nothing of DNS ... an application will 1) look up the name at
a DNS server, 2) retrieve the IP from the DNS server, and 3) connect to the IP
address.
Apache can do virtual domains ... HTTP 1.1 requires that you specify the
domain name.
- Erik
^ permalink raw reply
* Re: DNAT based on domain name instead of IP address
From: John A. Sullivan III @ 2004-01-28 23:45 UTC (permalink / raw)
To: Glen Lee Edwards; +Cc: netfilter
In-Reply-To: <1075332153.25415.98.camel@child-of-god.holiness.ch>
On Wed, 2004-01-28 at 18:22, Glen Lee Edwards wrote:
> I have several domains that use the same IP address. Can I DNAT them to
> different servers based on domain name instead of IP address using
> iptables? I've tried the following, but it isn't working:
>
> iptables -t nat -A PREROUTING -p tcp -d 1st.domain.com --dport 80 -j
> DNAT --to-destination 192.168.1.12:80
>
> iptables -t nat -A PREROUTING -p tcp -d 2nd.domain.com --dport 80 -j
> DNAT --to-destination 192.168.1.13:80
>
> Everything is being forwarded to 192.168.1.12 no matter which domain is
> used. It appears that the domains are first being translated into the
> IP address, which is used instead.
>
> Glen
I'm going to go way out on a limb here and speculate so if someone who
has actually looked at the code tells you otherwise, please listen to
them and not me!
I would assume that netfilter is only operating at layer 3. I believe
from an earlier enlightening post from Anthony Stone(?) that all domain
names are resolved to IP addresses when the rule is loaded and the rule
uses the layer three information, i.e., the IP address, to evaluate the
rule.
It sounds like you need something that will operate on the layer 7 data
since that's where the url/uri information is going to be. Perhaps a
proxy like squid has the ability to redirect traffic based upon layer 7
information.
I'm quite curious to see how you ultimately resolve this. Good luck -
John
--
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net
^ permalink raw reply
* Re: [PATCH] cpqarray update
From: Jeff Garzik @ 2004-01-28 23:44 UTC (permalink / raw)
To: Greg KH; +Cc: Hollis Blanchard, Linux Kernel Mailing List, francis.wiran
In-Reply-To: <40184845.3030008@pobox.com>
Jeff Garzik wrote:
> Actually I disagree with GregKH on this.
>
> The register/unregister functions need to be returning error codes,
> _not_ the count of interfaces registered. It is trivial to count the
> registered interfaces in the driver itself, but IMO far more important
> to propagate fatal errors back to the original caller.
Nevermind, this got fixed. I'm still worried about the '1' return
value, though, for zero controllers found.
Jeff
^ permalink raw reply
* Re: [PATCH] cpqarray update
From: Jeff Garzik @ 2004-01-28 23:39 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: Linux Kernel Mailing List, francis.wiran, Greg KH
In-Reply-To: <15D09760-51A9-11D8-AF96-000A95A0560C@us.ibm.com>
Hollis Blanchard wrote:
> I'm defining a new bus and had copied pci_module_init() to
> vio_module_init(). Here's what Greg KH had to say about that:
>
>> Eeek! I want to fix that code in pci_module_init() so it doesn't do
>> this at all. Please don't copy that horrible function. Just register
>> the driver with a call to vio_register_driver() and drop the whole
>> vio_module_init() completly. I'll be doing that for pci soon, and
>> there's no reason you want to duplicate this broken logic (you always
>> want your module probe to succeed, for lots of reasons...)
Actually I disagree with GregKH on this.
The register/unregister functions need to be returning error codes,
_not_ the count of interfaces registered. It is trivial to count the
registered interfaces in the driver itself, but IMO far more important
to propagate fatal errors back to the original caller.
This is what pci_module_init() does... returns an error if an error
occurred, zero if not. Further, use of pci_module_init() makes drivers
future-proof for a time when the API can better return fatal errors that
occur during the registration process.
As it stands now, pci_register_driver() -can- call functions which can
fail internally (see what driver_register calls...), unrelated to the
driver, and the driver will never ever know this.
That is an ugly flaw in most current foo_register_driver() APIs. Errors
are silently lost :(
Jeff
^ permalink raw reply
* Re: [PATCH] cpqarray update
From: Greg KH @ 2004-01-28 23:28 UTC (permalink / raw)
To: Wiran, Francis
Cc: Hollis Blanchard, Marcelo Tosatti, Jeff Garzik,
Linux Kernel Mailing List
In-Reply-To: <CBD6B29E2DA6954FABAC137771769D6504E1596D@cceexc19.americas.cpqcorp.net>
On Wed, Jan 28, 2004 at 05:10:29PM -0600, Wiran, Francis wrote:
>
> Ok. Here's the patch for that. At least until vio_module_init comes :)
Heh, you didn't actually try that patch, did you?
(hint, you need to check for a negative value...)
greg k-h
^ permalink raw reply
* Re: [linux-lvm] combining two vg's into one
From: Ken Fuchs @ 2004-01-28 23:38 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <20040129022341.88184.qmail@web80402.mail.yahoo.com>
Chris Conn wrote:
>I've got 2 vg's on two different partitions on
>different disks, one is my root vg and the other
>has /usr, /var and /tmp filesystems. I'd like to
>keep them on separate disks but use the same vg
>if I can, but I'm unsure how to combine them.
To keep / on one disk and /usr, /var and /tmp on another
disk, one volume group per disk as described above is the
best way to do this. There is no advantage to combining
the two volume groups together given that one wants to
keep logical volumes exclusively on one disk or the other.
Combining the two volume groups into one volume group
would allow logical volumes to span the two disks and
lvm striping, but that is contrary to the desire to keep
each logical volume exclusively on a particular disk.
>Do I have to move the lv's on disk2 out of their vg
>or can I just expand the vg on disk1 to include
>them? The filesystems are all ReiserFS, system
>is Slackware Linux 9.1.
Logical volumes can't be moved between volume groups.
If the physical extents of two volume groups are the
same and the limits of the destination group are not
exceeded, the two volume groups can be merged using
vgmerge(8). Go to step 9 below.
To join two volume groups with unequal logical extents:
1) Back up all logical volumes.
2) Remove all logical volumes in one volume group,
preferably the volume group NOT containing /,
using lvremove(8).
3) Remove all physical volumes from the volume
group to be removed using vgreduce(8).
4) Finally remove that volume group using vgremove(8).
5) Add all physical volumes that were in the removed
volume group into the remaining volume group using
vgextend(8)
6) Within the remaining volume group, create all logical
volumes removed in step 2 using lvcreate(8)
7) Create the desired filesystems for each logical
volume created in step 6.
8) Restore from backup each filesystem created in
step 7.
9) Modify /etc/fstab and any other configuration files
to reflect the volume group name change in the
"moved" (removed/recreated) volumes.
Sincerely,
Ken Fuchs <kfuchs@winternet.com>
^ permalink raw reply
* kernel oops with Reiser4/19.01.2004-fixed
From: Laurent Riffard @ 2004-01-28 23:37 UTC (permalink / raw)
To: reiserfs-list
[-- Attachment #1: Type: text/plain, Size: 522 bytes --]
Hello,
Here is the log of a kernel oops (kernel 2.6.1 + supermount +
Reiser4/19.01.2004-fixed). It happened last night. Azureus, a
java-written Bittorent client was running, it is set up to
download files to the faulty reiser4 filesystem.
[root@antares root]# df -h /dev/hdb7
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/hdb7 20G 16G 3,3G 83% /mnt/diske
[root@antares root]# mount
/dev/hdb7 on /mnt/diske type reiser4
(rw,noexec,nosuid,nodev,user=laurent)
--
laurent
[-- Attachment #2: syslog --]
[-- Type: text/plain, Size: 4512 bytes --]
Jan 28 04:15:40 antares kernel: attempt to access beyond end of device
Jan 28 04:15:40 antares kernel: hdb7: rw=1, want=1932196768, limit=41945652
Jan 28 04:15:40 antares kernel: reiser4[ktxnmgrd:run(2910)]: update_blocknr_hint_default (fs/reiser4/block_alloc.c:648)[zam-676]:
Jan 28 04:15:40 antares kernel: WARNING: block number 7307497714779250547 is too large to be used in a blocknr hint
Jan 28 04:15:40 antares kernel:
Jan 28 04:15:40 antares kernel: attempt to access beyond end of device
Jan 28 04:15:40 antares kernel: hdb7: rw=1, want=81755032, limit=41945652
Jan 28 04:15:40 antares kernel: reiser4[ktxnmgrd:run(2910)]: reiser4_handle_error (fs/reiser4/vfs_ops.c:1539)[foobar-42]:
Jan 28 04:15:40 antares kernel: reiser4 panicked cowardly: Filesystem error occured
Jan 28 04:15:40 antares kernel:
Jan 28 04:15:40 antares kernel: ------------[ cut here ]------------
Jan 28 04:15:40 antares kernel: kernel BUG at fs/reiser4/debug.c:75!
Jan 28 04:15:40 antares kernel: invalid operand: 0000 [#1]
Jan 28 04:15:40 antares kernel: CPU: 0
Jan 28 04:15:40 antares kernel: EIP: 0060:[reiser4_do_panic+16/208] Not tainted
Jan 28 04:15:40 antares kernel: EIP: 0060:[<c019e900>] Not tainted
Jan 28 04:15:40 antares kernel: EFLAGS: 00010246
Jan 28 04:15:40 antares kernel: EIP is at reiser4_do_panic+0x10/0xd0
Jan 28 04:15:40 antares kernel: eax: 00000000 ebx: c941c974 ecx: 00000001 edx: c50ce1f4
Jan 28 04:15:40 antares kernel: esi: 00000000 edi: c5427de8 ebp: c5427d98 esp: c5427d88
Jan 28 04:15:40 antares kernel: ds: 007b es: 007b ss: 0068
Jan 28 04:15:41 antares kernel: Process ktxnmgrd:run (pid: 2910, threadinfo=c5426000 task=c54392e0)
Jan 28 04:15:41 antares kernel: Stack: c941c974 00000001 c02e69f9 c5427da4 c5427dbc c01bcb83 c02e69df 00000001
Jan 28 04:15:41 antares kernel: c02e69d5 c02d605c c02e6757 00000603 cef5e4c8 c5427dd8 c01b7017 cef5e4c8
Jan 28 04:15:41 antares kernel: c5427de8 c21e3e84 c5427de8 c50ce1f4 c5427df4 c01b7045 c21e3e84 c5427de8
Jan 28 04:15:41 antares kernel: Call Trace:
Jan 28 04:15:41 antares kernel: [reiser4_handle_error+195/224] reiser4_handle_error+0xc3/0xe0
Jan 28 04:15:41 antares kernel: [<c01bcb83>] reiser4_handle_error+0xc3/0xe0
Jan 28 04:15:41 antares kernel: [finish_all_fq+151/160] finish_all_fq+0x97/0xa0
Jan 28 04:15:41 antares kernel: [<c01b7017>] finish_all_fq+0x97/0xa0
Jan 28 04:15:41 antares kernel: [current_atom_finish_all_fq+37/96] current_atom_finish_all_fq+0x25/0x60
Jan 28 04:15:41 antares kernel: [<c01b7045>] current_atom_finish_all_fq+0x25/0x60
Jan 28 04:15:41 antares kernel: [reiser4_write_logs+471/592] reiser4_write_logs+0x1d7/0x250
Jan 28 04:15:41 antares kernel: [<c01b2c67>] reiser4_write_logs+0x1d7/0x250
Jan 28 04:15:41 antares kernel: [commit_current_atom+309/496] commit_current_atom+0x135/0x1f0
Jan 28 04:15:41 antares kernel: [<c01abc25>] commit_current_atom+0x135/0x1f0
Jan 28 04:15:41 antares kernel: [atom_free+117/128] atom_free+0x75/0x80
Jan 28 04:15:41 antares kernel: [<c01ab745>] atom_free+0x75/0x80
Jan 28 04:15:41 antares kernel: [try_commit_txnh+200/384] try_commit_txnh+0xc8/0x180
Jan 28 04:15:41 antares kernel: [<c01ac258>] try_commit_txnh+0xc8/0x180
Jan 28 04:15:41 antares kernel: [commit_txnh+51/160] commit_txnh+0x33/0xa0
Jan 28 04:15:41 antares kernel: [<c01ac343>] commit_txnh+0x33/0xa0
Jan 28 04:15:41 antares kernel: [__wake_up_locked+34/48] __wake_up_locked+0x22/0x30
Jan 28 04:15:41 antares kernel: [<c01172d2>] __wake_up_locked+0x22/0x30
Jan 28 04:15:41 antares kernel: [txn_end+69/80] txn_end+0x45/0x50
Jan 28 04:15:41 antares kernel: [<c01ab495>] txn_end+0x45/0x50
Jan 28 04:15:41 antares kernel: [commit_some_atoms+175/208] commit_some_atoms+0xaf/0xd0
Jan 28 04:15:41 antares kernel: [<c01abf2f>] commit_some_atoms+0xaf/0xd0
Jan 28 04:15:41 antares kernel: [scan_mgr+47/80] scan_mgr+0x2f/0x50
Jan 28 04:15:41 antares kernel: [<c01b799f>] scan_mgr+0x2f/0x50
Jan 28 04:15:41 antares kernel: [ktxnmgrd+360/496] ktxnmgrd+0x168/0x1f0
Jan 28 04:15:41 antares kernel: [<c01b7708>] ktxnmgrd+0x168/0x1f0
Jan 28 04:15:41 antares kernel: [ktxnmgrd+0/496] ktxnmgrd+0x0/0x1f0
Jan 28 04:15:41 antares kernel: [<c01b75a0>] ktxnmgrd+0x0/0x1f0
Jan 28 04:15:41 antares kernel: [kernel_thread_helper+5/12] kernel_thread_helper+0x5/0xc
Jan 28 04:15:41 antares kernel: [<c0107029>] kernel_thread_helper+0x5/0xc
Jan 28 04:15:41 antares kernel:
Jan 28 04:15:41 antares kernel: Code: 0f 0b 4b 00 20 5e 2e c0 c7 04 24 b0 a1 2f c0 c7 44 24 04 40
^ permalink raw reply
* Re: [2.0.40-rc8] Works well
From: Markus Hästbacka @ 2004-01-28 23:37 UTC (permalink / raw)
To: David Weinehall; +Cc: Kernel Mailinglist
In-Reply-To: <20040128151727.GD16675@khan.acc.umu.se>
Btw - Are you going to announce the release of 2.0.40 (whenever it's
coming) or just put it on kernel.org?
Markus
^ permalink raw reply
* Re: Need help recovering lost partitions
From: Carl-Daniel Hailfinger @ 2004-01-28 23:35 UTC (permalink / raw)
To: dan; +Cc: matts, reiserfs-list
In-Reply-To: <20040128143848.27765.h003.c001.wm@mail.ngenllc.com.criticalpath.net>
dan@ngenllc.com wrote:
> So how can I scan the partition for the old
> superblocks? gpart and parted weren't picking them up,
> but I know they were there. And the 6GB of data it
> found is much less then the size of the partition
> (50GB), which makes me think that some data might still
> be there (i.e. only 100 * (6/50) % of the data could
> have been overwritten).
If you did reiserfsck --rebuild-tree --scan-whole-partition on the
unpartitioned hard drive, it is very likely that this reduced your chance
of rescueing some data to zero.
It all depends on how much money you're willing to spend. For starters, I
would recommend you to try the support offered by Namesys. Since they
wrote reiserfs they should have the best chance rescuing you data if it is
still on disk. If the data has already been overwritten by your actions,
you could try some data rescure company who claim to restore overwritten
data with a scanning tunneling microscope or somesuch.
The namesys support has helped a colleague of mine to restore all of his
data albeit some filenames were lost. The files themselves were
uncorrupted. And another big advantage of namesys is that they charge only
about 1/10th of the amount a commercial data rescue company would bill
you. (based on quotes from the web sites of the respective companies)
HTH,
Carl-Daniel
^ permalink raw reply
* Re: [RFC/PATCH, 1/4] readX_check() performance evaluation
From: David Mosberger @ 2004-01-28 23:35 UTC (permalink / raw)
To: Andi Kleen
Cc: davidm, davidm, iod00d, ishii.hironobu, linux-kernel, linux-ia64
In-Reply-To: <20040128210132.2b0e5a96.ak@suse.de>
>>>>> On Wed, 28 Jan 2004 21:01:32 +0100, Andi Kleen <ak@suse.de> said:
Andi> Seriously you can count it somewhere and present it in sysfs
Andi> or /proc. Or log it somewhere else and supply a special
Andi> utility to show them that makes it clear that the events are
Andi> hardware and not software related. I suppose if your server
Andi> vendor is serious they will supply a tool to read the firmware
Andi> log from a running system.
Andi> But printks enabled by default are a bad idea (and a bug too
Andi> BTW - printk called from MCE handlers can randomly deadlock)
No argument here. I didn't get/see the earlier part of this
discussion so I didn't realize you were complaining about printks
only. Never mind.
--david
^ permalink raw reply
* Re: pmdisk working on ppc (WAS: Help port swsusp to ppc)
From: Pavel Machek @ 2004-01-28 23:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Michael Schmitz, Michael Schmitz, Hugang, Patrick Mochel,
Nigel Cunningham, ncunningham, linuxppc-dev list
In-Reply-To: <1075326924.5658.299.camel@gaston>
Hi!
> > > > Battery requests might have been underway; pmud is running. If I read
> > > > pmu_suspend() right, pending battery requests should result in pmu_suspend
> > > > waiting for them to finish?
> > >
> > > Normally yes... pmud isn't running at this point (all processes are frozen)
> >
> > OK. I put a mdelay(100) between the PMU_SYSTEM_READY request and the
> > pmu_suspend() call in pmu_sys_resume and it seems to work so far. Side
> > note: if you are saving a large system and have multiple swap files, play
> > with swap priorities to make sure the pages are swapped out to the file
> > _not_ used for suspend.
>
> Ah ? What's up ? suspend trashes the swap ? That's very bad...
No, it does not.
But swap space is shared between suspend and swap. And if that place
is full (unlikely), you've got a problem.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [RFC/PATCH, 1/4] readX_check() performance evaluation
From: David Mosberger @ 2004-01-28 23:35 UTC (permalink / raw)
To: Andi Kleen
Cc: davidm, davidm, iod00d, ishii.hironobu, linux-kernel, linux-ia64
In-Reply-To: <20040128210132.2b0e5a96.ak@suse.de>
>>>>> On Wed, 28 Jan 2004 21:01:32 +0100, Andi Kleen <ak@suse.de> said:
Andi> Seriously you can count it somewhere and present it in sysfs
Andi> or /proc. Or log it somewhere else and supply a special
Andi> utility to show them that makes it clear that the events are
Andi> hardware and not software related. I suppose if your server
Andi> vendor is serious they will supply a tool to read the firmware
Andi> log from a running system.
Andi> But printks enabled by default are a bad idea (and a bug too
Andi> BTW - printk called from MCE handlers can randomly deadlock)
No argument here. I didn't get/see the earlier part of this
discussion so I didn't realize you were complaining about printks
only. Never mind.
--david
^ permalink raw reply
* Re: salinfo-0.4 patch
From: Ben Woodard @ 2004-01-28 23:32 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <1075324928.25461.273.camel@xenophanes>
On Wed, 2004-01-28 at 13:50, Keith Owens wrote:
> On 28 Jan 2004 13:22:08 -0800,
> Ben Woodard <woodard@redhat.com> wrote:
> >Here is a tiny patch for salinfo-0.4. There is a problem with when it
> >deals with multiple errors. The decoded error messages fill up with
> >progressively more white space.
>
> That should not occur, the ++indent/--indent lines should be matched.
> Instead of forcing indent back to 0, please find the missing line and
> fix it. Correct code is better than an arbitrary reset.
>
> If you have a sample of nested indent that will help track down the
> bug, send it to kaos@sgi.com.
>
> >While poking around in the iprint function, I also found an error
> >message that looks like it is better suited for stderr rather than
> >stdout so I retargetted it.
>
> No. I deliberately used stdout so the error message would appear at
> the end of the truncated file on disk, to tell the viewer that this
> particular file was incomplete. stderr is useless when salinfo_decode
> is run from init.d.
OK how about this patch. I think I found the missing --indent.
diff -u -r1.1 mca.c
--- mca.c 2004/01/28 23:28:03 1.1
+++ mca.c 2004/01/28 23:28:27
@@ -857,6 +857,7 @@
}
if (pcei->valid.oem_data)
platform_pci_comp_err_print(&pcei->header, p_oem_data);
+ --indent;
}
/* Format and log the platform specifie error record section data */
^ permalink raw reply
* (2.4) ext3 - commit=NNN overridden by laptopmode (bdflush)
From: Micha Feigin @ 2004-01-28 23:30 UTC (permalink / raw)
To: lkml
When looking into the ext3 commit code I saw that it has a commit=NNN
mount option for specifying the log update time (same as in 2.6). The
problem is that this value is overridden by the laptopmode code that
was added which uses the value of get_buffer_flushtime which takes its
value from bdflush, which makes that option obsolete.
It looks to me that the bdflush code should be taken back out of the
ext3 code.
I don't mind doing it but only if there is interest.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.