| 1 |
On Mar 18, 2014, at 2:37 AM, Martin Dummer <martin.dummer@×××.net> wrote: |
| 2 |
|
| 3 |
> -----BEGIN PGP SIGNED MESSAGE----- |
| 4 |
> Hash: SHA1 |
| 5 |
> |
| 6 |
> Am 17.03.2014 18:27, schrieb Richard Yao: |
| 7 |
>> I am pleased to announce the release of 3.4.49. |
| 8 |
> |
| 9 |
> Thanks for this fast release! |
| 10 |
|
| 11 |
I plan to resume frequent genkernel releases. Ideally, I want to do a release at least as often as every two months. That is not quite what past levels were, but it is close enough. |
| 12 |
|
| 13 |
>> * btrfs support improvements from Martin Drummer. He sent an early |
| 14 |
>> version to me, but it had a few issues that caused me to send it back to |
| 15 |
>> him for revision. |
| 16 |
> |
| 17 |
> Yes, and after the git patch I sent on 3.3.2014 my development continued and |
| 18 |
> I discovered that there is some code missing for the case that the multi-disk- |
| 19 |
> btrfs is "not clean" and the initrd can only try to mount it in "degraded" |
| 20 |
> mode. |
| 21 |
> Here comes my question: In that situation - what is the best way the initrd |
| 22 |
> should behave? |
| 23 |
> |
| 24 |
> - - inform the user and ask if / should be mounted in degraded mode |
| 25 |
> (allow the user to exit to a shell and do some troubleshooting, implement |
| 26 |
> a kernel cmdline parameter e.g. "dobtrfs=degraded" to override the question |
| 27 |
> |
| 28 |
> - - never try this automatically, just print a message that a kernel cmdline parameter |
| 29 |
> e.g. "dobtrfs=degraded" is needed and stop boot process |
| 30 |
> |
| 31 |
> - - none of the above, instead do this: ...... |
| 32 |
|
| 33 |
ZFS will boot into a degraded state on any ZFS system. Unless the btrfs code is prone to false positives on degraded configurations, it would make sense for btrfs to do the same. |
| 34 |
|
| 35 |
>> 1. genkernel will now automatically ehnable --zfs on systems that have a |
| 36 |
>> zfs root filesystem, even when it is not specified, unless explicitly |
| 37 |
>> overwritten in genkernel.conf. |
| 38 |
> |
| 39 |
> I like to see this auto-support for btrfs, too. |
| 40 |
|
| 41 |
I broke the changes into two patches. One is filesystem independent and another is a one-line patch enabling it for ZFS. It was done in this way to allow reuse in other filesystems such as btrfs, but zfs is currently the only consumer. Since I know that you are working on btrfs, I decided to wait for your changes before touching that code. |
| 42 |
|
| 43 |
>> * Add a CONTRIBUTING file to the repository documenting how to send |
| 44 |
>> patches to me for new releases. |
| 45 |
> |
| 46 |
> Very good idea! I think I received most of the future contents as an email from |
| 47 |
> you! |
| 48 |
|
| 49 |
That is correct. |
| 50 |
|
| 51 |
>> We have plenty of bugs that need |
| 52 |
>> attention and insufficient developer time |
| 53 |
> |
| 54 |
> Yes, and with my work on btrfs support bug #499716 can be closed. |
| 55 |
> |
| 56 |
> I will look through the list of bugs an see if I can work on some other open bugs... |
| 57 |
|
| 58 |
That would be great. :) |
Archives