Bakul Shah wrote:
+--
| [cc'ed Rob in case he wishes to chime in]
+-
No, I think you covered most of it quite well [including the bit
about "grep -m" not working properly in the case of pipes, sockets,
special files, etc.], thanks.
Yes, I know that "grep(1)" only promises that "-
On Mon, 07 Jun 2010 00:13:28 +0200 =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=
wrote:
>
> The reason why head(1) doesn't work as expected is that it uses buffered
> I/O with a fairly large buffer, so it consumes more than it needs. The
> only way to make it behave as the OP expected is to use unbuffe
On 06/06/10 15:13, Dag-Erling Smørgrav wrote:
The second command will receive whatever is left after the first is
done. Otherwise, read(1) loops wouldn't work. You chose a poor
example, since cat(1) consumes*everything*.
Fair enough. My point remains though, using this technique is liable to
Doug Barton writes:
> If you have a 2 line file named foo that looks like this:
> one
> two
>
> Then do: cat foo | (cat ; echo 'blah' ; cat)
>
> you get:
> one
> two
> blah
>
>
> which seems to indicate to me that unless the first command is a shell
> builtin that the first command is going to re
On 06/06/10 07:33, Dag-Erling Smørgrav wrote:
Doug Barton writes:
Bakul Shah writes:
$ ps|(head -1; grep sh)
PID TT STAT TIME COMMAND
I don't understand why you think this would work. There is no input to
the grep command. The only reason it exits at all is that you are
executing
:> It would be interesting to see a blogbench comparison between UFS
:> and ZFS on the same hw/disk.
:
:
:I'll do it, just tell me how do you want to run the tests.
:
:The system params are:
:
:8GB Memory
:2x72GB SCSI HDD
:2x3.4Ghz Xeon
:Overall: Dell Poweredge 1850. With no raid installed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/6/10 7:20 PM, Matthew Dillon wrote:
> It would be interesting to see a blogbench comparison between UFS
> and ZFS on the same hw/disk.
I'll do it, just tell me how do you want to run the tests.
The system params are:
8GB Memory
2x72GB
:All of these tests have been apples vs. oranges for years.
:
:The following seems to be true, though:
:
:a) FreeBSD sequential write performance in UFS has always been less than
:optimal.
If there's no read activity sequential write performance should be
maximal with UFS. The keyphrase
Doug Barton writes:
> Bakul Shah writes:
> > $ ps|(head -1; grep sh)
> >PID TT STAT TIME COMMAND
> I don't understand why you think this would work. There is no input to
> the grep command. The only reason it exits at all is that you are
> executing in a subshell.
The output from ps i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/5/10 2:43 AM, Igor Mozolevsky wrote:
> On 5 June 2010 00:58, Adam PAPAI wrote:
>
>> How can I tune my disk to make it faster? Is it possible? What is the
>> reason of the really slow I/O with more than 4 threads? What do you
>> recommend me to d
Interesting. Looking at dwarf parsing sources in DTrace, and there are
comments that suggest that ctfconvert should've been able to deal with
zero-sized arrays.
Look at die_sou_resolve() in cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c
One observation, if you add a real member to the union that
11 matches
Mail list logo
