diff options
Diffstat (limited to 'hurd')
| -rw-r--r-- | hurd/libstore/nbd_store.mdwn | 11 | ||||
| -rw-r--r-- | hurd/running/qemu/writeback_caching.mdwn | 35 | ||||
| -rw-r--r-- | hurd/translator/pfinet/ipv6.mdwn | 24 |
3 files changed, 65 insertions, 5 deletions
diff --git a/hurd/libstore/nbd_store.mdwn b/hurd/libstore/nbd_store.mdwn index 8560fd44..3f161ba8 100644 --- a/hurd/libstore/nbd_store.mdwn +++ b/hurd/libstore/nbd_store.mdwn @@ -23,6 +23,17 @@ License|/fdl]]."]]"""]] Perhaps the protocol was extended? +### IRC, freenode, #hurd, 2012-12-20 + + <youpi> if somebody has time to spend, building the nbd package makes + pfinet crash + + +#### IRC, freenode, #hurd, 2012-12-21 + + <youpi> (in the testsuite) + + ## [xNBD](https://bitbucket.org/hirofuchi/xnbd/) diff --git a/hurd/running/qemu/writeback_caching.mdwn b/hurd/running/qemu/writeback_caching.mdwn index c9c53e3e..3b6c366b 100644 --- a/hurd/running/qemu/writeback_caching.mdwn +++ b/hurd/running/qemu/writeback_caching.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 -Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, +2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -13,7 +13,8 @@ License|/fdl]]."]]"""]] [[!tag open_issue_documentation]] -IRC, freenode, #hurd, 2011-06-07 + +# IRC, freenode, #hurd, 2011-06-07 <braunr> hm, i guess i should have used cache=writeback with kvm before starting the debian installer :/ @@ -57,7 +58,8 @@ IRC, freenode, #hurd, 2011-06-07 <braunr> well, if there is no I/O during downloading, downloading is faster :) -IRC, freenode, #hurd, 2011-06-08 + +# IRC, freenode, #hurd, 2011-06-08 <braunr> youpi: does xen provide disk caching options ? <youpi> through a blktap, probably @@ -70,7 +72,8 @@ IRC, freenode, #hurd, 2011-06-08 <braunr> it really makes the hurd run a lot faster <braunr> as a workaround for emulators until I/O is reworked, ofc -IRC, freenode, #hurd, 2011-06-09 + +# IRC, freenode, #hurd, 2011-06-09 <gnu_srs> braunr recommends to use writeback caching with kvm. Is this really recommended with the frequent crashes I experience? @@ -88,3 +91,25 @@ IRC, freenode, #hurd, 2011-06-09 as soon as the data is present in the host page cache. This is safe as long as you trust your host. If your host crashes or loses power, then the guest may experience data corruption." (from the qemu manpage) + + +# IRC, freenode, #hurd, 2012-12-30 + + <gg0> http://bugs.debian.org/622319#51 + <gg0> braunr: just pointing out writeback is default since qemu 1.3.0 + <gg0> that makes hurd VMs faster by default :p + <braunr> ahh :) + <gg0> about data loss I had read (qemu man pages?) it may occur in case of + loss of power + <braunr> well yes + <gg0> probably on hurd may occur even with writethrough due to non + journaled ext2 + <braunr> yes but the hurd flushes everything (and i mean everything) every + 5 seconds + <gg0> http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg02682.html + <braunr> so it's actually less likely to lose data because of the hurd than + because of power loss + <braunr> what i meant earlier is that we've never experienced unexpected + data loss because of qemu writeback policy + <braunr> if data is in the host cache and you lose power, qemu or not, you + lose data diff --git a/hurd/translator/pfinet/ipv6.mdwn b/hurd/translator/pfinet/ipv6.mdwn index d30cc850..edd31017 100644 --- a/hurd/translator/pfinet/ipv6.mdwn +++ b/hurd/translator/pfinet/ipv6.mdwn @@ -70,3 +70,27 @@ Amongst other things, support for [[IOCTL]]s is missing. <braunr> ok <braunr> i'd like to set this up on my VMs but it looks bugged :/ <braunr> i can't manage to set correctly set the gateway + + +### IRC, freenode, #hurd, 2012-12-12 + + <braunr> hm, pfinet seems not to support ipv6 well at all :( + <pinotree> braunr: really? + <braunr> pinotree: i can't manage to set a global address statically and + make it communicate with neighbours + <braunr> pfinet receives the advertisement (during neighbour discovery) but + immediately resends the same solicitation again + <gnu_srs> According to the pfinet/README IPv6 support was added in 2007 + from Linux 2.2.14 while the rest is from 2.2.12 + <braunr> according to me, bugs were added at the same time + <braunr> :p + <braunr> in addition, ipv6 in linux 2.2 was, uh, not working well either + <braunr> even with 2.4, it was still messy + <gnu_srs> maybe we should try to upgrade the TCP/IP stack to something + 2.6+? + <gnu_srs> (a lot of work though) + <braunr> we've already had that discussion + <gnu_srs> Yes. What is the best way forward, a GSoC task? + <gnu_srs> There is one already: + http://www.gnu.org/software/hurd/community/gsoc/project_ideas/tcp_ip_stack.html + <braunr> personally, i'd advocate resuing code from netbsd |