Archive-Team
/
zfs
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 103 Wiki Activity

Merge commit 'refs/top-bases/linux-libspl' into linux-libspl

This commit is contained in:
Brian Behlendorf 2009-03-20 14:40:10 -07:00
parent 19d685e446 d83c361158
commit 73c605353b
2 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
ChangeLog
View File

@ -4,7 +4,7 @@
* : Rebased to ZFS b108 from OpenSolaris * : Rebased to ZFS b108 from OpenSolaris
* configure.ac, *Makefile.am: Build system updatei. This includes * configure.ac, *Makefile.am: Build system update. This includes
resolving various build issues and adding support for the remaining resolving various build issues and adding support for the remaining
common build targets. Available targets now include: common build targets. Available targets now include:
@ -26,7 +26,7 @@
This will produce two binary RPMs with correct 'requires' This will produce two binary RPMs with correct 'requires'
dependencies for your kernel. One will contain all zfs modules dependencies for your kernel. One will contain all zfs modules
and support utilities, the other is a devel package for compiling and support utilities, the other is a devel package for compiling
additional kernel modules which are dependant on the zfs. additional kernel modules which are dependent on the zfs.
zfs-x.y.z-1_<kernel version>.x86_64.rpm zfs-x.y.z-1_<kernel version>.x86_64.rpm
zfs-devel-x.y.2-1_<kernel version>.x86_64.rpm zfs-devel-x.y.2-1_<kernel version>.x86_64.rpm

6
TODO
View File

@ -5,7 +5,7 @@ SUMMARY OF MAJOR KNOWN PROBLEMS IN v0.4.3 (Development Release)
- Implement something similar to the Solaris devid support to ensure - Implement something similar to the Solaris devid support to ensure
ZFS properly locates your disks even when moved. The current port ZFS properly locates your disks even when moved. The current port
is dependant on using something like udev to ensure this can never is dependent on using something like udev to ensure this can never
happen but this is not a viable long term solution. happen but this is not a viable long term solution.
- Implement something like Solaris's sysevent support to detect when - Implement something like Solaris's sysevent support to detect when
@ -33,7 +33,7 @@ SUMMARY OF MAJOR KNOWN PROBLEMS IN v0.4.3 (Development Release)
lt-ztest: ../../lib/libzpool/taskq.c:199: Assertion lt-ztest: ../../lib/libzpool/taskq.c:199: Assertion
`pthread_create(&tq->tq_threadlist[t], NULL, taskq_thread, tq) == 0' failed. `pthread_create(&tq->tq_threadlist[t], NULL, taskq_thread, tq) == 0' failed.
2) Reproducable on my RHEL5-x86_64 box after perhaps an hour: 2) Reproducible on my RHEL5-x86_64 box after perhaps an hour:
ztest -V -T 18000 ztest -V -T 18000
5 vdevs, 7 datasets, 23 threads, 18000 seconds... 5 vdevs, 7 datasets, 23 threads, 18000 seconds...
@ -44,7 +44,7 @@ SUMMARY OF MAJOR KNOWN PROBLEMS IN v0.4.3 (Development Release)
dsl_dataset_hold_obj(dp, dsobj, ((char *)__func__), &ds) (0x0 == 0x2)' failed. dsl_dataset_hold_obj(dp, dsobj, ((char *)__func__), &ds) (0x0 == 0x2)' failed.
child died with signal 6 child died with signal 6
3) Reproducable on my RHEL5-x86_64 box after perhaps an hour: 3) Reproducible on my RHEL5-x86_64 box after perhaps an hour:
ztest -V -T 18000 ztest -V -T 18000
5 vdevs, 7 datasets, 23 threads, 18000 seconds... 5 vdevs, 7 datasets, 23 threads, 18000 seconds...