k...@munnari.oz.au (Robert Elz) writes:
>I had a similar thought ... seems like it would be a reasonable idea to me.
>Perhaps even some variation of the vnd driver to allow it to access
>hardware partitions, rather than only files.
I once tried to make vnd work on VBLK "files", but there were som
rhia...@falu.nl (Rhialto) writes:
>Would it make sense to create a separate layered device that converts
>the block size of its underlying device? At least that would separate
>the problem and make it simpler. And it might be useful in its own
>right, for instance when you dd a file system image t
Date:Wed, 2 Dec 2015 02:08:49 +0100
From:Rhialto
Message-ID: <20151202010849.gp28...@falu.nl>
| Would it make sense to create a separate layered device that converts
| the block size of its underlying device?
I had a similar thought ... seems like it would be a r
On Fri 27 Nov 2015 at 08:48:07 +0700, Robert Elz wrote:
> To fix this the CGD would need to fully emulate a 512 byte drive, regardless
> of sector size, actually doing RMW cycles to allow updating 512 bytes in the
> middle of a 4K sector (or whatever size it happens to be.)
Would it make sense to
Date:Sun, 29 Nov 2015 10:47:17 + (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| Maybe this:
| http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/vnd.c.diff
Yes, works fine. Including, as expected, the label issue - the driver
might still make a l
> } A quick test shows that it works with a NFS file. I don't know
> } how stable that is.
>
> It's documented as not working, and I know from experience
> that it doesn't work, unless something has changed recently. My
> test case, at least the most recent one from memory, has to do with
>
Date:Sun, 29 Nov 2015 10:47:17 + (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| Maybe this:
| http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/vnd.c.diff
Looks reasonable ... I'll see if I can find time to test it in the next
12 hours or so...
Date:Sun, 29 Nov 2015 03:41:02 -0800
From:John Nemeth
Message-ID: <201511291141.tatbf2vx023...@server.cornerstoneservice.ca>
| BTW, the dom0 is running 6.1.5.
I believe that 6.1.5 (and likely any other 6.1.x that might appear)
doesn't have the sparse file fixes (o
On Sun, Nov 29, 2015 at 10:52:18AM +, Michael van Elst wrote:
> mlel...@serpens.de (Michael van Elst) writes:
> >The bizarre disklabel seems to be another problem.
>
> vnd.c says:
>/*
> * For historical reasons, if there's no disklabel
>
jnem...@cue.bc.ca (John Nemeth) writes:
>Xen is told to use a file for backing store, a script sets up a
>VND and then uses that as Xen really wants a device. It doesn't
>work when the ISO device is on a NAS,
How does it fail?
--
--
Michael van Elst
Internet: m
On Nov 29, 10:38am, Michael van Elst wrote:
} Subject: Re: In-kernel units for block numbers, etc ...
} jnem...@cue.bc.ca (John Nemeth) writes:
}
} > On a side note, if the backend is just a file, why doesn't
} >vnd(4) work with NFS?
}
} A quick test shows that it works with a
mlel...@serpens.de (Michael van Elst) writes:
>The bizarre disklabel seems to be another problem.
vnd.c says:
/*
* For historical reasons, if there's no disklabel
* present, all partitions must be FS_BSDFFS and
* occupy the entire
mlel...@serpens.de (Michael van Elst) writes:
>k...@munnari.oz.au (Robert Elz) writes:
>>vndconfig worked (or reported no errors) in all cases. The 512 byte
>>sector on the unholy file produces a bizarre default disklabel though,
Maybe this:
http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/vnd.c
jnem...@cue.bc.ca (John Nemeth) writes:
> On a side note, if the backend is just a file, why doesn't
>vnd(4) work with NFS?
A quick test shows that it works with a NFS file. I don't know
how stable that is.
--
--
Michael van Elst
Internet: mlel...@serpens.d
k...@munnari.oz.au (Robert Elz) writes:
>The vnd driver is (from what I can tell from skimming it) trying to be
>smart - if it can (if it thinks it can) it bypasses the generic file i/o
>and goes directly to the underlying device's, what a comment at the start
>of vnd.c says is ...
> * NOTE 1: If
On Nov 29, 12:05am, Michael van Elst wrote:
} k...@munnari.oz.au (Robert Elz) writes:
}
} >I havem't looked carefully yet, but does vnd have the RMW behaviour to
} >allow an emulated small sector drive to exist on a big sector underlying.
}
} It doesn't need to, the backend is a file and you can
Date:Sun, 29 Nov 2015 00:05:37 + (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| It doesn't need to, the backend is a file and you can access arbitrary
| byte positions.
You would think so, and that is probably what should happen, but I just
di
k...@munnari.oz.au (Robert Elz) writes:
>I havem't looked carefully yet, but does vnd have the RMW behaviour to
>allow an emulated small sector drive to exist on a big sector underlying.
It doesn't need to, the backend is a file and you can access arbitrary
byte positions. The "RMW behaviour" is
Date:Sat, 28 Nov 2015 22:34:25 +0100
From:Michael van Elst
Message-ID: <20151128213424.gc6...@serpens.de>
| > that would at least allow data to be recovered, by default, from
| > the wrong sized media.
There's no reason there could not be a userland tool that wou
On Sun, Nov 29, 2015 at 08:11:58AM +1100, matthew green wrote:
>
> i think it should use 512 byte crypto blocks in all cases, using
> offset in DEV_BSIZE units as part of the IV, at least by default.
>
> that would at least allow data to be recovered, by default, from
> the wrong sized media.
It
On Sun, Nov 29, 2015 at 03:33:31AM +0700, Robert Elz wrote:
>
> I wondered about that, but wasn't sure if the disklabel read might be
> needed for the dkwedge_discover() that immediately follows.
The wedge autodiscover code doesn't need the disklabel, it gets
some geometry data from the driver it
> The current code operates on full sectors and encodes the sector number
> into the data.
>
> Modifying this to encode multiple 512 byte blocks instead and using
> block numbers instead of sector numbers looks straight forward to me.
>
> We just have to decide if that is a good thing. Or maybe i
k...@munnari.oz.au (Robert Elz) writes:
> | The correct thing is therefore to drop the dk_getdisklabel call.
> | Can you verify that this just solves the problem?
>Yes, that works too.
Committed.
--
--
Michael van Elst
Internet: mlel...@serpens.de
Date:Sat, 28 Nov 2015 19:58:19 + (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| The correct thing is therefore to drop the dk_getdisklabel call.
| Can you verify that this just solves the problem?
Yes, that works too.
I wondered about that, b
On Sun, Nov 29, 2015 at 03:06:10AM +0700, Robert Elz wrote:
> Date:Sun, 29 Nov 2015 01:22:08 +0700
> From:Robert Elz
> Message-ID: <19896.1448734...@andromeda.noi.kre.to>
>
> | Stuff related to PR 41704 generating a panic in my setup ...
> | Anyone have any sugges
Date:Sun, 29 Nov 2015 01:22:08 +0700
From:Robert Elz
Message-ID: <19896.1448734...@andromeda.noi.kre.to>
| Stuff related to PR 41704 generating a panic in my setup ...
| Anyone have any suggestions?
Actually, the (or a) fix for this is astoundingly easy, and I'm
k...@munnari.oz.au (Robert Elz) writes:
>This is (it appears) caused by this line in cgdioctl() ...
>dk_getdisklabel(dksc, 0 /* XXX ? (cause of PR 41704) */);
>The 0 ((dev_t)0) and XXX have been there since cgd.c 1.1, so this
>is nothing new!
That's vp->v_rdev stored as cs->sc_tdev. A v
Date:Sat, 28 Nov 2015 14:57:08 + (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| I've just committed a few fixes for disks with non-512byte sectors
| to HEAD.
|
| cgd now works on my drive with 1k sectors.
Thanks, works for me too (I didn'
jan.m.daniels...@gmail.com (Jan Danielsson) writes:
>On 27/11/15 00:20, Robert Elz wrote:
>[---]
>> Making the CGD believe its underlying sectors are 4K panics the system.
>> (That's about as far as I got, but I think the problem is related to
>> translation between units, being done when it shoul
g...@ir.bbn.com (Greg Troxel) writes:
>1) What do FreeBSD, Linux, and Illumos do? OpenBSD/Dragonfly/others?
If I'm not mistaken, this looks like:
FreeBSD - native disk blocks
Linux - native disk blocks
Illumos - DEV_BSIZE
OpenBSD - DEV_BSIZE
NetBSD - DEV_BSIZE
DragonFly - native disk blocks
Ami
A few questions to help address the bytes vs units notion:
1) What do FreeBSD, Linux, and Illumos do? OpenBSD/Dragonfly/others?
2) How would either strategy interact with ZFS? Long term, NetBSD
needs to get 1st-class ZFS support, and what ZFS needs/wants is an
interesting issue for that goal,
On Fri, Nov 27, 2015 at 05:40:39PM +, David Holland wrote:
> On Thu, Nov 26, 2015 at 11:25:21PM +, Michael van Elst wrote:
> > dholland-t...@netbsd.org (David Holland) writes:
> >
> > >The problem I see with carrying around unit values at runtime (besides
> > >potential overhead)
On Thu, Nov 26, 2015 at 11:25:21PM +, Michael van Elst wrote:
> dholland-t...@netbsd.org (David Holland) writes:
>
> >The problem I see with carrying around unit values at runtime (besides
> >potential overhead) is that at least in FS-level code it'll make a
> >huge mess. FFS, for example
t...@panix.com (Thor Lancelot Simon) writes:
>Yes. CCD supports layouts that RAIDframe doesn't, ones that are more
>efficient for many real-world workloads: with CCD, it's possible to
>concatenate drives or stripe them with enormous, prime stripe units, so
>that concurrent I/O streams are highly
k...@munnari.oz.au (Robert Elz) writes:
>Personally, I'd like to avoid restrictions like
> "thus preventing the use of sectors maller than 512 bytes"
>there's no reason for it.
Well, one reason is that you can still do (some) calculations with
block addresses without overflowing integer ar
On Thu, Nov 26, 2015 at 07:33:00PM +, David Holland wrote:
> On Thu, Nov 26, 2015 at 11:38:14PM +0700, Robert Elz wrote:
> > (for 4K sector drives, cgd and lvm both give you 1/8 the space that
> > you should have had on the device.)
>
> Ewww
>
> > ccd (especially if combining a 4k byte
This is a reply to a message on the netbsd-users list, which drifted
into a discussion which eventually spawned this thread on teck-kern,
where (post drifting) it is more appropriate...
mlel...@serpens.de said:
| The newfs command queries the sector size, calculates the filesystem
| parameters
Date:Fri, 27 Nov 2015 01:54:04 +0100
From:Jan Danielsson
Message-ID: <5657a9ac.8030...@gmail.com>
| I took a quick stab at making cgd work on a disk with 4K sectors a
| while back, but $OTHER_STUFF got in the way.
That's largely what has happened with me, so far.
On 27/11/15 00:20, Robert Elz wrote:
[---]
> Making the CGD believe its underlying sectors are 4K panics the system.
> (That's about as far as I got, but I think the problem is related to
> translation between units, being done when it shouldn't be.)
I took a quick stab at making cgd work on a
Date:Thu, 26 Nov 2015 23:50:36 + (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| You need to copy the sector size from the underlying disk and you
| need to fix a few cases where DEV_BSIZE is used for buffer sizes.
Yes, did that, that's what le
Date:Thu, 26 Nov 2015 16:12:34 -0800
From:John Nemeth
Message-ID: <201511270012.tar0cyuf007...@server.cornerstoneservice.ca>
| I would hope the answer is no, considering how much that would
| complicate things, not to mention the slow down (i.e. doing a singl
On Nov 27, 6:00am, Robert Elz wrote:
}
} Date:Fri, 27 Nov 2015 07:12:50 +1100
} From:matthew green
} Message-ID: <18094.1448568...@splode.eterna.com.au>
}
} | FWIW, i "fixed" raidframe on 4K disks a few years back.
}
} Do we allow mirroring where one drive is 512
k...@munnari.oz.au (Robert Elz) writes:
>It is easy to see why this happens in the CGD source, I think there's
>even an XXX comment that is related ... an easy "fix" would just be to
>multiply the size by 8 (by the appropriate factor really, of course)
>but that then makes the CGD look like it is
k...@munnari.oz.au (Robert Elz) writes:
>Date:Fri, 27 Nov 2015 07:12:50 +1100
>From:matthew green
>Message-ID: <18094.1448568...@splode.eterna.com.au>
> | FWIW, i "fixed" raidframe on 4K disks a few years back.
>Do we allow mirroring where one drive is 512 byte sec
dholland-t...@netbsd.org (David Holland) writes:
>The problem I see with carrying around unit values at runtime (besides
>potential overhead) is that at least in FS-level code it'll make a
>huge mess. FFS, for example, has hardware-level sectors, DEV_BSIZE
>blocks, fragments, its own blocks, and m
Date:Thu, 26 Nov 2015 19:33:00 +
From:David Holland
Message-ID: <20151126193300.ga28...@netbsd.org>
| Ewww
It is easy to see why this happens in the CGD source, I think there's
even an XXX comment that is related ... an easy "fix" would just be to
multiply
k...@munnari.oz.au (Robert Elz) writes:
>Unfortunately, once we add the "stacked" devices (cgd, and ccd for sure,
>perhaps lvm and raidframe, I haven't looked at those enough to know)
>the model breaks down, and we get incorrect conversions.
That isn't true.
>Currently at least cgd and (I belie
Date:Fri, 27 Nov 2015 07:12:50 +1100
From:matthew green
Message-ID: <18094.1448568...@splode.eterna.com.au>
| FWIW, i "fixed" raidframe on 4K disks a few years back.
Do we allow mirroring where one drive is 512 byte sectors, and the
other is 4K ?
If so (and I'd ho
> raidframe I haven't thought about, or investigated, at all.
FWIW, i "fixed" raidframe on 4K disks a few years back. i say "fixed"
because of the way a lot of storage seems to work, it must continue
to be accessed in 4K sector mode. i have a umass adapter that will
export >2TB disks as 4K secto
On Thu, Nov 26, 2015 at 11:38:14PM +0700, Robert Elz wrote:
> (for 4K sector drives, cgd and lvm both give you 1/8 the space that
> you should have had on the device.)
Ewww
> ccd (especially if combining a 4k byte sector device with a 512 byte sector
> device) is simply a mess - perhaps a
50 matches
Mail list logo
