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
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
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 -
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:
*Bump*
On Jul 10, 2014, at 12:33, Kent R. Spillner kspill...@acm.org 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 (char
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 Thursday, April 17, 2014, Otto Moerbeek o...@drijf.net 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 11:16:00PM -0700, Philip Guenther wrote:
On Thursday, April 17, 2014, Otto Moerbeek o...@drijf.net 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
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 o...@drijf.net wrote:
On Wed, Apr 16, 2014 at 11:16:00PM -0700, Philip Guenther wrote:
On Thursday, April 17, 2014, Otto Moerbeek o...@drijf.net wrote:
...
But bear in
On Thu, Apr 17, 2014 at 5:31 AM, Brandon Mercer
yourcomputer...@gmail.com 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 o...@drijf.net wrote:
On Wed, Apr 16, 2014 at 11:16:00PM -0700, Philip Guenther wrote:
On
Em 17-04-2014 07:34, Abel Abraham Camarillo Ojeda escreveu:
On Thu, Apr 17, 2014 at 5:31 AM, Brandon Mercer
yourcomputer...@gmail.com 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 o...@drijf.net wrote:
On Wed,
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
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 of
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
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 athom...@athompso.net wrote:
Yes, but the very nature of the discussion concerns VMs, where the point is
to multiplex the physical
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 cores
* Adam Thompson athom...@athompso.net [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
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.
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
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
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 format
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 discovered
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 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
25 matches
Mail list logo
