[developer] Re: [openzfs/openzfs] 7614 zfs device evacuation/removal (#482)

Thank you - much appreciated! -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/482#issuecomment-361767038 -- openzfs-developer Archives: https://

[developer] Re: [openzfs/openzfs] 8809 libzpool should leverage work done in libfakekernel (#494)

Closed #494 via 8a051e3a96224ab3cb2a4b0c7999aeff7a572ef5. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/494#event-1449511613 -- openzfs-develop

[developer] Re: [openzfs/openzfs] 7614 zfs device evacuation/removal (#482)

@ivucica - the final commit message for `f539f1e` ended up wrong, so this commit closes #482 and does add support for removal of top-level mirror vdevs as described in #482 commit message. Sorry for the confusion. -- You are receiving this because you are subscribed to this thread. Reply to thi

Re: [developer] degradation in zfs compatibility

On 30 January 2018 at 09:48, Igor Kozhukhov wrote: > I’d like to propose to do something: > - all interfaces in public headers = public interfaces - available for > external applications and should be saved as is But what is a "public header"? In this case, you're talking about a header file tha

[developer] Re: [openzfs/openzfs] 8969 Cannot boot from RAIDZ with parity > 1 (#526)

Closed #526 via 5bd0e35536618d75ac043932c42efed58ff5def1. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/526#event-144907 -- openzfs-develop

Re: [developer] degradation in zfs compatibility

> On Tue, Jan 30, 2018 at 8:06 AM, Igor Kozhukhov > wrote: > Hi all, > > I have found one degradation after illumos update: > illumos #6902 > https://github.com/illumos/illumos-gate/commit/0d8fa8f8eba3ea46bc79d73445009505d1dd5d7d > >

[developer] Re: [openzfs/openzfs] XXX Does removing bootfs_008_pos change anything? (#525)

Closed #525. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/525#event-1449084830 -- openzfs-developer Archives: https://openzfs.topicbox.com/gr

Re: [developer] degradation in zfs compatibility

On Tue, Jan 30, 2018 at 8:06 AM, Igor Kozhukhov wrote: > Hi all, > > I have found one degradation after illumos update: > illumos #6902 > https://github.com/illumos/illumos-gate/commit/ > 0d8fa8f8eba3ea46bc79d73445009505d1dd5d7d > > One public interface has been changed and applications with link

Re: [developer] degradation in zfs compatibility

On 30 January 2018 at 08:06, Igor Kozhukhov wrote: > I have found one degradation after illumos update: > illumos #6902 > https://github.com/illumos/illumos-gate/commit/0d8fa8f8eba3ea46bc79d73445009505d1dd5d7d > > One public interface has been changed and applications with links to old > interface

[developer] Re: [openzfs/openzfs] 8809 libzpool should leverage work done in libfakekernel (#494)

@gwr While I tend to agree with you, I'd like to push this forward and get it landed as-is; since it's been lingering in the current state for a while. I'm not opposed to making the changes you suggest in a follow up patch, though. Are you OK with that? I'm going to open the RTI as the tests hav

[developer] degradation in zfs compatibility

Hi all, I have found one degradation after illumos update: illumos #6902 https://github.com/illumos/illumos-gate/commit/0d8fa8f8eba3ea46bc79d73445009505d1dd5d7d One public interface has been changed and applications with links to old interface are failed. As example, it is Jenkins with oracle

[developer] Re: [openzfs/openzfs] 8809 libzpool should leverage work done in libfakekernel (#494)

That said, I hate to hold things up. If you think the (rather limited) cred implementation is generic enough, at least for today's consumers, I guess it's OK for this to go ahead. It does mean that if and when a consumer comes along that needs real credentials (i.e. NFS?) we'll need to change