{5} Assigned, Active Tickets by Owner (Full Description) (4 matches)

List tickets assigned, group by ticket owner. This report demonstrates the use of full-row display.

jaharkes (4 matches)

Ticket Summary Component Milestone Type Created
Description
#1647 reintegration and shadow copies coda Coda-7.0.0 defect 04/10/08

There are several problems when we create shadow copies for reintegration. A shadow copy for a container file is created so that a new writer doesn't clobber the data we want to reintegrate. We currently create these copies when reintegration starts, but there are several issues with this.

  1. If the file is not written to during reintegration, we wasted resources making a unnecessary copy.
  2. If the file was already reopened for writing, the container may already be clobbered. In this case the client will trigger an assertion at some point because the file size is not what we expected.
  3. If the file is opened for writing after making the shadow copy, but the client crashes we lose both the shadow copy (not persistently stored) as well as the rewritten version as we move owrite files out of the way on startup because we don't trust their contents.

A long time ago shadow copies were made when we opened a file for writing that had a CML entry. This solves cases (a) and (b), but it doesn't solve (c). We moved away from that implementation because it performed an swap of the original and shadow container files in case the original container file was being backfetched which in turn made us lose the newly written contents when venus was restarted even if we had a clean shutdown.

The current idea is to go back to the old scheme of only copying on the open for write, but this time create a full clone of the current fsobj (a shadow fsobj). The cml entry remains associated with the original, but it will for the rest be unlinked and dereferenced to the point that once the cml entry is reintegrated or optimized away the fso can be recycled. The cloned fso will take over for the old one and will be the one that is opened for writing.

#703 Linux ENOENT & ESTALE errors coda defect 02/07/03

We're seeing ENOENT and ESTALE errors with 2.4 Linux kernels.

The ESTALE is caused by an NFS close-to-open patch that went into 2.4.18 or .19, which bugs out when '.' or '..' is opened, but the dentry revalidation test fails.

First of all the test is too generic, so any filename starting with '.' will receive the additional test. Second, they are revalidating the path instead of the object, I don't see how they would handle a rename from a different client correctly, as the current test 'reinstates' the old pathname in the dcache. The NFS-close-to-open semantics really should be using inode_revalidate, which would fix the Coda problems wrt ESTALE errors.

The ENOENT failure is triggered by concurrent directory lookups when the second thread finds a cached dentry in real_lookup after blocking on the i_sem.

Ultimately both cases are caused by Coda's 'volatile' pathnames, these are used for mountpoints and repair subtrees to make it easier to turn symlinks into directories and vv.

Jan

#715 Use of C++ objects in RVM defect 03/10/03

The use of C++ objects in RVM should be avoided as much as possible. Their layout/implementation could change when the compiler, compiler options (-march) or libstdc++ changes.

#1666 rename get_tid rvm Undefined defect 02/06/09

rvm's get_tid function should be renamed, a name collision causes transactions to fail.

Note: See TracReports for help on using and creating reports.