From 5d233af2da807256a495006196ef2f371c38cc40 Mon Sep 17 00:00:00 2001 From: Brian Behlendorf Date: Wed, 21 Jan 2009 11:26:19 -0800 Subject: [PATCH] Add TODO --- .topmsg | 4 ++-- TODO | 29 +++++++++++++++++++++++++++++ 2 files changed, 31 insertions(+), 2 deletions(-) create mode 100644 TODO diff --git a/.topmsg b/.topmsg index caa807ee54..03967cdff5 100644 --- a/.topmsg +++ b/.topmsg @@ -13,7 +13,7 @@ features which require tweaks to the build system should appear on the relevant topic branches. All autotools products which result from autogen.sh are commited to the linux-configure-branch. -This branch also contains the META, ChangeLog, AUTHORS, and -README, files. +This branch also contains the META, ChangeLog, AUTHORS, TODO, +and README, files. Signed-off-by: Brian Behlendorf diff --git a/TODO b/TODO new file mode 100644 index 0000000000..15fcc8c65a --- /dev/null +++ b/TODO @@ -0,0 +1,29 @@ +SUMMARY OF MAJOR KNOWN PROBLEMS IN v0.4.0 (Development Release) + +- 'zpool create' hangs in the create ioctl() when initializing a new pool + backed by loopback devices. The lo-raid0 configuration easily recreates + this issue. I currently suspect a problem in vdev_disk.c implementation + is causing this, but I have not yet looked to closely. On the surface + things appear to be fine when creating the pool with real device or files. + + ./zpios.sh -c lo-raid0 -t tiny -v + +- SPLError: 10167:1968:(spl-kmem.c:1286:spl_kmem_cache_reap_now()) + ASSERTION(skc->skc_magic == SKC_MAGIC) failed + + The above assertion is overserved when perform more IO than can be fully + cached by the ARC. The Linux VM applies back pressure to the slab which + in turn detect what appears to be memory corruption. I've seen a few + flavors of this so far, so I'm not yet convinced this is actually an + issue with the SPL slab. It may just be the most common victim, more + investigation is needed. It is also possible the new untested vdev_disk.c + is to blame. A lot of work is needed here. + +- SPLError: 7324:1224:(dnode.c:304:dnode_create()) VERIFY3(0` >= 1`) + + When enabling debugging in ZFS with the --enable-debug configure option + we always trip the following VERIFY. This issue was present in the + previous 0.3.3 release and was avoided simply by leaving debugging + disabled until it could be explained. Well it has not just gone + always with the update to b105 so we need to run it to ground and + explain what is going on.