di_size is u_int64_t in both struct ufs1_dinode and ufs2_dinode, and
strlen returns size_t. Adjust link_len and len declarations to match
and drop now-redundant unsigned cost from bcopy.
Index: sys/lib/libsa/ufs.c
===
RCS file: /work
Simplify if-conditions by removing explicit != 0.
Index: sys/lib/libsa/ufs.c
===
RCS file: /work/cvsroot/src/sys/lib/libsa/ufs.c,v
retrieving revision 1.24
diff -p -u -r1.24 ufs.c
--- sys/lib/libsa/ufs.c 22 Jul 2014 18:03:03 -
Next, use NULL instead of casting 0 to pointer types.
Index: sys/lib/libsa/ufs.c
===
RCS file: /work/cvsroot/src/sys/lib/libsa/ufs.c,v
retrieving revision 1.22
diff -p -u -r1.22 ufs.c
--- sys/lib/libsa/ufs.c 30 May 2013 19:19:09 -
Sorry, let me split this into smaller diffs to ease review.
First up, the diff below removes a redundant cast: buf is declared a
char * so there's no need to cast it to a char *. I noticed the same
issue in ufs.c, too, so fix it in both places.
Index: ufs.c
==
*Bump*
> On Jul 10, 2014, at 12:33, "Kent R. Spillner" wrote:
>
> Ping.
>
>> On Thu, May 01, 2014 at 01:22:56PM -0500, Kent R. Spillner wrote:
>> After sending my previous reply I noticed that you already committed
>> your diff, so here are my comments again in the form of a proper diff:
>>
>>
Ping.
On Thu, May 01, 2014 at 01:22:56PM -0500, Kent R. Spillner wrote:
> After sending my previous reply I noticed that you already committed
> your diff, so here are my comments again in the form of a proper diff:
>
> * Use NULL instead of casting 0 to pointer types
>
> * Remove unnecessary (c
After sending my previous reply I noticed that you already committed
your diff, so here are my comments again in the form of a proper diff:
* Use NULL instead of casting 0 to pointer types
* Remove unnecessary (char *) cast on buf because buf was already
declared as char *
* Simplify "if ((rc
> On Apr 16, 2014, at 17:03, Brandon Mercer wrote:
>
> On Wed, Apr 16, 2014 at 08:05:57PM +, Miod Vallat wrote:
>>> The other day I was doing an install in qemu-kvm and newfs was taking
>>> forever, to the tune of hours. This is similar to formatting on arm
>>> boards. In my quest to track
On Wed, Apr 16, 2014 at 05:29:36PM -0500, Shawn K. Quinn wrote:
> On Wed, Apr 16, 2014, at 03:05 PM, Miod Vallat wrote:
>[responding to Brandon Mercer who wrote:]
> > > The other day I was doing an install in qemu-kvm and newfs was taking
> > > forever, to the tune of hours. This is similar to
On Thu, Apr 17, 2014 at 12:22:44PM -0500, Adam Thompson wrote:
> Given the single-threaded nature of much of the kernel, what applications do
> you run where multiple CPUs makes much of a difference to OpenBSD?
>
You're a narrow-minded troll.
* Adam Thompson [2014-04-17 19:31]:
> I've found that having multiple cores available can speed up a desktop, and
> certain classes of cpu-bound server applications, and not much else.
MP speeds up all userland-heavy tasks a lot.
MP doesn't yet speed up kernel-heavy tasks as much as it should.
Em 17-04-2014 14:30, Adam Thompson escreveu:
> Yes, but the very nature of the discussion concerns VMs, where the
> point is to multiplex the physical CPUs into multiple VMs in
> user-controllable chunks. A VM with one vCPU is perfectly reasonable
> and normal.
>
> I've found that having multiple c
Please take this discussion elsewhere. This email is about being able
to boot off ffs2 not your ability to run vm's.
On Thu, Apr 17, 2014 at 1:30 PM, Adam Thompson wrote:
> Yes, but the very nature of the discussion concerns VMs, where the point is
> to multiplex the physical CPUs into multiple V
Yes, but the very nature of the discussion concerns VMs, where the point is to
multiplex the physical CPUs into multiple VMs in user-controllable chunks. A
VM with one vCPU is perfectly reasonable and normal.
I've found that having multiple cores available can speed up a desktop, and
certain c
On Thu, Apr 17, 2014 at 12:22:44PM -0500, Adam Thompson wrote:
> Given the single-threaded nature of much of the kernel, what applications do
> you run where multiple CPUs makes much of a difference to OpenBSD?
Come on, a machine runs multiple processes...
>
> Also, switching from IDE to any
Given the single-threaded nature of much of the kernel, what applications do
you run where multiple CPUs makes much of a difference to OpenBSD?
Also, switching from IDE to any of the supported SCSI, SAS or SATA disk types
also produces a noticeable improvement. I'm not sure if those are availab
Em 17-04-2014 07:34, Abel Abraham Camarillo Ojeda escreveu:
> On Thu, Apr 17, 2014 at 5:31 AM, Brandon Mercer
> wrote:
>> It will take me about that long to newfs the 10 kvm's I plan on using ;)
>>
>> On Thu, Apr 17, 2014 at 5:09 AM, Otto Moerbeek wrote:
>>> On Wed, Apr 16, 2014 at 11:16:00PM -07
On Thu, Apr 17, 2014 at 5:31 AM, Brandon Mercer
wrote:
> It will take me about that long to newfs the 10 kvm's I plan on using ;)
>
> On Thu, Apr 17, 2014 at 5:09 AM, Otto Moerbeek wrote:
>> On Wed, Apr 16, 2014 at 11:16:00PM -0700, Philip Guenther wrote:
>>
>>> On Thursday, April 17, 2014, Otto
It will take me about that long to newfs the 10 kvm's I plan on using ;)
On Thu, Apr 17, 2014 at 5:09 AM, Otto Moerbeek wrote:
> On Wed, Apr 16, 2014 at 11:16:00PM -0700, Philip Guenther wrote:
>
>> On Thursday, April 17, 2014, Otto Moerbeek wrote:
>> ...
>>
>> > But bear in mind that ffs2 has m
On Wed, Apr 16, 2014 at 11:16:00PM -0700, Philip Guenther wrote:
> On Thursday, April 17, 2014, Otto Moerbeek wrote:
> ...
>
> > But bear in mind that ffs2 has more overhead in terms of metadata.
> > IMO, making it the default is not a good idea.
> >
>
> You have fewer than 24 years left to enj
On Thursday, April 17, 2014, Otto Moerbeek wrote:
...
> But bear in mind that ffs2 has more overhead in terms of metadata.
> IMO, making it the default is not a good idea.
>
You have fewer than 24 years left to enjoy FFS v1...
On Wed, Apr 16, 2014 at 06:37:08PM -0400, Brandon Mercer wrote:
> As I mentioned previously, this does more than just allow you to boot
> from TB disks. When I configure a 100GB disk in qemu-kvm it takes
> forever to format. On small flash installations, formatting is faster
> there as well. You d
As I mentioned previously, this does more than just allow you to boot
from TB disks. When I configure a 100GB disk in qemu-kvm it takes
forever to format. On small flash installations, formatting is faster
there as well. You don't need a 1TB disk to benefit from ffs2.
On Wed, Apr 16, 2014 at 3:57
On Wed, Apr 16, 2014, at 03:05 PM, Miod Vallat wrote:
[responding to Brandon Mercer who wrote:]
> > The other day I was doing an install in qemu-kvm and newfs was taking
> > forever, to the tune of hours. This is similar to formatting on arm
> > boards. In my quest to track down why, I discovere
On Wed, Apr 16, 2014 at 08:05:57PM +, Miod Vallat wrote:
> > The other day I was doing an install in qemu-kvm and newfs was taking
> > forever, to the tune of hours. This is similar to formatting on arm
> > boards. In my quest to track down why, I discovered that ffs2 takes far
> > less time to
> The other day I was doing an install in qemu-kvm and newfs was taking
> forever, to the tune of hours. This is similar to formatting on arm
> boards. In my quest to track down why, I discovered that ffs2 takes far
> less time to format than ffs1 (about 30 seconds for the entire disk).
>
> I've
The other day I was doing an install in qemu-kvm and newfs was taking
forever, to the tune of hours. This is similar to formatting on arm
boards. In my quest to track down why, I discovered that ffs2 takes far
less time to format than ffs1 (about 30 seconds for the entire disk).
I've put together
27 matches
Mail list logo
