Hi all.
I didn't really know where to post this question, so I try
"hackers"
When rc starts, root filesystem is already mounted readonly, and fsck
runs ok, then root is remounted read/write.
Later, if root filesystem is remounted readonly, then fsck is called,
it will says "NO WRITE ACCESS
On Fri, Oct 13, 2006 at 09:41:37AM +0200, VANHULLEBUS Yvan wrote:
>
> Later, if root filesystem is remounted readonly, then fsck is called,
> it will says "NO WRITE ACCESS".
mount -ur /
or if your fstab is not matching the system configuration
mount -ur /dev/$ROOT /
Joerg
_
On Fri, Oct 13, 2006 at 10:04:07AM +0200, Joerg Sonnenberger wrote:
> On Fri, Oct 13, 2006 at 09:41:37AM +0200, VANHULLEBUS Yvan wrote:
> >
> > Later, if root filesystem is remounted readonly, then fsck is called,
> > it will says "NO WRITE ACCESS".
>
> mount -ur /
>
> or if your fstab is not ma
Sounds like f/w issues. Let me see if I can't get some traction out of
LSI on this.
On 10/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
The problems are:
(1) It's not a RAID-0 Vol but a RAID-1 (The PCI-X card reports it
correctly, but not the PCI-Express. This should not differ.
(2) The RA
On 10/7/06, Kris Kennaway <[EMAIL PROTECTED]> wrote:
On Fri, Oct 06, 2006 at 09:35:31AM +0400, Andrew Pantyukhin wrote:
> I wonder if there is a way to deal with statically linked binaries,
> which use vulnerable libraries.
The best way is to track them down and force them all to link
dynamicall
Doug Barton wrote:
> Oliver Fromme wrote:
> > In this case, the "real" time is much larger than the
> > "user" time. I guess that's the overhead of 85677 files
> > and 23399 directories (according to find(1)). :-)
>
> Did you perform your tests once only with each method, and one right
>
Oliver Fromme wrote:
Meanwhile I had a quick look at the code: gzip uses some
optimized assembler code ... Maybe that's the reason why
gzip is noticeably faster.
Anyone care to try this test on PPC, ARM, or Sparc?
There's a move afoot to replace the GPL gzip with
a more openly-licensed gzip
> From: Pieter de Goeje <[EMAIL PROTECTED]>
> Subject: Re: "tar -c|gzip" faster than "tar -cz"?!?
>
> The tar|gzip command uses 18% less CPU and is 10% faster. It
> is clear the HDD is the bottleneck.
Now it's clear to me :)
This makes sense if tar is single-threaded: there's only one thread of
In the last episode (Oct 13), Tim Kientzle said:
> Oliver Fromme wrote:
> >Meanwhile I had a quick look at the code: gzip uses some optimized
> >assembler code ... Maybe that's the reason why gzip is noticeably
> >faster.
>
> Anyone care to try this test on PPC, ARM, or Sparc?
The only assembly
:
:Just a silly one but are you guys using the same
:version of gzip, would be worth just checking?
It could also simply be a piplining issue. If the pipe inbetween the
'tar' and the 'gzip' is too small (whether gzip is internal to tar
or not), then the 'tar' portion could wind up ge
On Fri, Oct 13, 2006 at 10:04:07AM +0200, Joerg Sonnenberger wrote:
> On Fri, Oct 13, 2006 at 09:41:37AM +0200, VANHULLEBUS Yvan wrote:
> >
> > Later, if root filesystem is remounted readonly, then fsck is called,
> > it will says "NO WRITE ACCESS".
>
> mount -ur /
I'm pretty sure that's what he
On Fri, Oct 13, 2006 at 03:45:34PM +0200, Oliver Fromme wrote:
> Meanwhile I had a quick look at the code: gzip uses some
> optimized assembler code (for x86 and 680x0), while libz
> doesn't have such a thing. Maybe that's the reason why
> gzip is noticeably faster.
I'm not sure what happened in
Kelly Hall <[EMAIL PROTECTED]> wrote:
> > From: Pieter de Goeje <[EMAIL PROTECTED]>
> > Subject: Re: "tar -c|gzip" faster than "tar -cz"?!?
> >
> > The tar|gzip command uses 18% less CPU and is 10% faster. It
> > is clear the HDD is the bottleneck.
>
> Now it's clear to me :)
>
> This
On Friday 13 October 2006 13:42, Rick C. Petty wrote:
> On Fri, Oct 13, 2006 at 10:04:07AM +0200, Joerg Sonnenberger wrote:
> > On Fri, Oct 13, 2006 at 09:41:37AM +0200, VANHULLEBUS Yvan wrote:
> > >
> > > Later, if root filesystem is remounted readonly, then fsck is called,
> > > it will says "NO
:On Fri, Oct 13, 2006 at 03:45:34PM +0200, Oliver Fromme wrote:
:> Meanwhile I had a quick look at the code: gzip uses some
:> optimized assembler code (for x86 and 680x0), while libz
:> doesn't have such a thing. Maybe that's the reason why
:> gzip is noticeably faster.
:
:I'm not sure what hap
On Fri, Oct 13, 2006 at 02:16:51PM -0400, John Baldwin wrote:
> On Friday 13 October 2006 13:42, Rick C. Petty wrote:
> >
> > I'm pretty sure that's what he tried (hence "remounted readonly"). I've
> > noticed this behavior as well and it is quite frustrating. If you boot
> > single-user, / will
Hi there,
This has been noticed on all 5.x, 6.x, and 7.0 systems around
here:
adjkerntz and xterm processes have VBAD type vnodes attached
to some of their descriptors. What this is supposed to mean?
$ fstat | grep -w bad
root xterm9766 - - bad-
root xter
:Hi there,
:
:This has been noticed on all 5.x, 6.x, and 7.0 systems around
:here:
:
:adjkerntz and xterm processes have VBAD type vnodes attached
:to some of their descriptors. What this is supposed to mean?
:
:$ fstat | grep -w bad
:root xterm9766 - - bad-
:..
On Fri, Oct 13, 2006 at 01:43:38PM -0700, Matthew Dillon wrote:
> These are almost certainly descriptors whos vnodes have been
> revoked with revoke(). This most commonly occurs on tty (or pty)
> descriptors. For example, if you logout of a tty session
> with background processes
On Fri, Oct 13, 2006 at 05:18:57PM +0400, Andrew Pantyukhin wrote:
> On 10/7/06, Kris Kennaway <[EMAIL PROTECTED]> wrote:
> >On Fri, Oct 06, 2006 at 09:35:31AM +0400, Andrew Pantyukhin wrote:
> >> I wonder if there is a way to deal with statically linked binaries,
> >> which use vulnerable librarie
>From: Oliver Fromme <[EMAIL PROTECTED]>
> > > The tar|gzip command uses 18% less CPU and is 10% faster. It
> > > is clear the HDD is the bottleneck.
> >
> > Now it's clear to me :)
> >
> > This makes sense if tar is single-threaded: there's only one thread of
> > execution, and it can either b
21 matches
Mail list logo
