# this should fail.. but the last chmod succeeds even though there are # no execute permissions on the directory. (pauln@born-of-fire:pauln)$ mkdir c (pauln@born-of-fire:pauln)$ touch c/d (pauln@born-of-fire:pauln)$ chmod 644 c (pauln@born-of-fire:pauln)$ chmod 640 c/d # however, if a few seconds go by.. (pauln@born-of-fire:pauln)$ chmod 640 c/d chmod: cannot access `c/d': Permission denied
Testing a patch which fixes an attribute bug which prevents a parent directory from having its time attrs updated in the slash2 client and mds fcmh cache.
(pauln@born-of-fire:pauln)$ (cd /s2/pjd-fstest-20080816/ && sudo prove -r tests/mkdir) tests/mkdir/00.t .. ok tests/mkdir/01.t .. ok tests/mkdir/02.t .. ok tests/mkdir/03.t .. ok tests/mkdir/04.t .. ok tests/mkdir/05.t .. ok tests/mkdir/06.t .. ok tests/mkdir/07.t .. ok tests/mkdir/08.t .. ok tests/mkdir/09.t .. ok tests/mkdir/10.t .. ok tests/mkdir/11.t .. ok tests/mkdir/12.t .. ok All tests successful. Files=13, Tests=105, 3 wallclock secs ( 0.11 usr 0.02 sys + 3.72 cusr 0.31 csys = 4.16 CPU) Result: PASS
Working on the mkdir test suite..
(pauln@born-of-fire:pjd-fstest-20080816)$ prove tests/mkdir/ tests/mkdir/00.t .. 29/36 stat returned -1 [: 61: Illegal number: ENOENT stat returned -1 [: 63: Illegal number: ENOENT stat returned -1 [: 65: Illegal number: ENOENT tests/mkdir/00.t .. Failed 18/36 subtests tests/mkdir/01.t .. ok tests/mkdir/02.t .. ok tests/mkdir/03.t .. ok tests/mkdir/04.t .. ok tests/mkdir/05.t .. Failed 7/12 subtests tests/mkdir/06.t .. Failed 7/12 subtests tests/mkdir/07.t .. ok tests/mkdir/08.t .. ok tests/mkdir/09.t .. ok tests/mkdir/10.t .. ok tests/mkdir/11.t .. ok tests/mkdir/12.t .. ok Test Summary Report ------------------- tests/mkdir/00.t (Wstat: 0 Tests: 36 Failed: 18) Failed tests: 18-35 tests/mkdir/05.t (Wstat: 0 Tests: 12 Failed: 7) Failed tests: 4-10 tests/mkdir/06.t (Wstat: 0 Tests: 12 Failed: 7) Failed tests: 4-10 Files=13, Tests=105, 3 wallclock secs ( 0.10 usr 0.04 sys + 3.70 cusr 0.37 csys = 4.21 CPU) Result: FAIL
==15268== ==15268== HEAP SUMMARY: ==15268== in use at exit: 163,287,806 bytes in 40,358 blocks ==15268== total heap usage: 1,653,889 allocs, 1,613,531 frees, 803,951,246 bytes allocated ==15268== ==15268== LEAK SUMMARY: ==15268== definitely lost: 0 bytes in 0 blocks ==15268== indirectly lost: 0 bytes in 0 blocks ==15268== possibly lost: 13,876,803 bytes in 36,714 blocks ==15268== still reachable: 149,411,003 bytes in 3,644 blocks ==15268== suppressed: 0 bytes in 0 blocks ==15268== Rerun with --leak-check=full to see details of leaked memory ==15268== ==15268== For counts of detected and suppressed errors, rerun with: -v ==15268== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
Yesterday, I revised the way we build ZFS which we use in the MDS backend for the file system metadata storage.
Previously, there was a make(1) target zbuild that branded two compilations of the ZFS codes: one that built the standalone executables such as zpool(8) and zfs-fuse(8) and the second which constructed a library providing the core ZFS functionality for use in slashd which we call libzfs-fuse.a.
The problem was that, anytime hacking on ZFS occurs, because both compilations reused object file naming, you had to clear out both compilations and build both over again from scratch. So I eliminated the zbuild target in place of our common make infrastructure targets. Now, to build ZFS, simply descend into ${ROOTDIR}/zfs and run make there.
The new build process maintains separate object directories for the standalone utilities and for libzfs-fuse.a which minimizes the amount of work to be done when source files shared between them get modified. This approach also has the benefit of reducing surprises and unique make targets to bootstrap the system codes by following the general procedure for building our components.