exofs

fs/exofs/dir.c new file +58 -0

+	de->inode_no = cpu_to_le64(inode->i_ino);
+	exofs_set_de_type(de, inode);
+	err = exofs_commit_chunk(page, pos, len);
+	exofs_put_page(page);
+	dir->i_mtime = dir->i_ctime = CURRENT_TIME;
+	mark_inode_dirty(dir);
+}
+
+int exofs_add_link(struct dentry *dentry, struct inode *inode)
+{
+	struct inode *dir = dentry->d_parent->d_inode;
+	const unsigned char *name = dentry->d_name.name;
+	int namelen = dentry->d_name.len;
+	unsigned chunk_size = exofs_chunk_size(dir);
+	unsigned reclen = EXOFS_DIR_REC_LEN(namelen);
+	unsigned short rec_len, name_len;
+	struct page *page = NULL;
+	struct exofs_sb_info *sbi = inode->i_sb->s_fs_info;
+	struct exofs_dir_entry *de;
+	unsigned long npages = dir_pages(dir);
+	unsigned long n;
+	char *kaddr;
+	loff_t pos;
+	int err;
+
+	for (n = 0; n <= npages; n++) {
+		char *dir_end;
+
+		page = exofs_get_page(dir, n);
+		err = PTR_ERR(page);
+		if (IS_ERR(page))
+			goto out;
+		lock_page(page);
+		kaddr = page_address(page);
+		dir_end = kaddr + exofs_last_byte(dir, n);
+		de = (struct exofs_dir_entry *)kaddr;
+		kaddr += PAGE_CACHE_SIZE - reclen;
+		while ((char *)de <= kaddr) {
+			if ((char *)de == dir_end) {
+				name_len = 0;
+				rec_len = chunk_size;
+				de->rec_len = cpu_to_le16(chunk_size);
+				de->inode_no = 0;
+				goto got_it;
+			}
+			if (de->rec_len == 0) {
+				EXOFS_ERR("ERROR: exofs_add_link: "
+					"zero-length directory entry");
+				err = -EIO;
+				goto out_unlock;
+			}
+			err = -EEXIST;
+			if (exofs_match(namelen, name, de))
+				goto out_unlock;
+			name_len = EXOFS_DIR_REC_LEN(de->name_len);
+			rec_len = le16_to_cpu(de->rec_len);
+			if (!de->inode_no && rec_len >= reclen)
+				goto got_it;

fs/exofs/dir.c new file +4 -0

+int exofs_delete_entry(struct exofs_dir_entry *dir, struct page *page)
+{
+	struct address_space *mapping = page->mapping;
+	struct inode *inode = mapping->host;

fs/exofs/dir.c new file +6 -0

+		if (de->rec_len == 0) {
+			EXOFS_ERR("ERROR: exofs_delete_entry:"
+				"zero-length directory entry");
+			err = -EIO;
+			goto out;
+		}

fs/exofs/dir.c new file +26 -0

+	if (pde)
+		pde->rec_len = cpu_to_le16(to - from);
+	dir->inode_no = 0;
+	err = exofs_commit_chunk(page, pos, to - from);
+	inode->i_ctime = inode->i_mtime = CURRENT_TIME;
+	mark_inode_dirty(inode);
+	sbi->s_numfiles--;
+out:
+	exofs_put_page(page);
+	return err;
+}
+
+int exofs_make_empty(struct inode *inode, struct inode *parent)
+{
+	struct address_space *mapping = inode->i_mapping;
+	struct page *page = grab_cache_page(mapping, 0);
+	unsigned chunk_size = exofs_chunk_size(inode);
+	struct exofs_dir_entry *de;
+	int err;
+	void *kaddr;
+
+	if (!page)
+		return -ENOMEM;
+
+	err = exofs_write_begin(NULL, page->mapping, 0, chunk_size, 0,
+							&page, NULL);

fs/exofs/inode.c +62 -0

+	exofs_set_de_type(de, inode);
+	kunmap_atomic(page, KM_USER0);
+	err = exofs_commit_chunk(page, 0, chunk_size);
+fail:
+	page_cache_release(page);
+	return err;
+}
+
 
+struct inode *exofs_new_inode(struct inode *dir, int mode)
+{
+	struct super_block *sb;
+	struct inode *inode;
+	struct exofs_i_info *oi;
+	struct exofs_sb_info *sbi;
+	struct osd_request *or;
+	struct osd_obj_id obj;
+	int ret;
+
+	sb = dir->i_sb;
+	inode = new_inode(sb);
+	if (!inode)
+		return ERR_PTR(-ENOMEM);
+
+	oi = exofs_i(inode);
+
+	init_waitqueue_head(&oi->i_wq);
+	set_obj_2bcreated(oi);
+
+	sbi = sb->s_fs_info;
+
+	sb->s_dirt = 1;
+	inode->i_uid = current->cred->fsuid;
+	if (dir->i_mode & S_ISGID) {
+		inode->i_gid = dir->i_gid;
+		if (S_ISDIR(mode))
+			mode |= S_ISGID;
+	} else {
+		inode->i_gid = current->cred->fsgid;
+	}
+	inode->i_mode = mode;
+
+	inode->i_ino = sbi->s_nextid++;
+	inode->i_blkbits = EXOFS_BLKSHIFT;
+	inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME;
+	oi->i_commit_size = inode->i_size = 0;
+	spin_lock(&sbi->s_next_gen_lock);
+	inode->i_generation = sbi->s_next_generation++;
+	spin_unlock(&sbi->s_next_gen_lock);
+	insert_inode_hash(inode);
+
+	mark_inode_dirty(inode);
+
+	obj.partition = sbi->s_pid;
+	obj.id = inode->i_ino + EXOFS_OBJ_OFF;
+	exofs_make_credential(oi->i_cred, &obj);
+
+	or = osd_start_request(sbi->s_dev, GFP_KERNEL);
+	if (unlikely(!or)) {
+		EXOFS_ERR("exofs_new_inode: osd_start_request failed\n");
+		return ERR_PTR(-ENOMEM);
+	}
+

fs/exofs/namei.c new file +33 -0

+		osd_end_request(or);
+		return ERR_PTR(-EIO);
+	}
+	atomic_inc(&sbi->s_curr_pending);
+
+	return inode;
+}
 
+static int exofs_mkdir(struct inode *dir, struct dentry *dentry, int mode)
+{
+	struct inode *inode;
+	int err = -EMLINK;
+
+	if (dir->i_nlink >= EXOFS_LINK_MAX)
+		goto out;
+
+	inode_inc_link_count(dir);
+
+	inode = exofs_new_inode(dir, S_IFDIR | mode);
+	err = PTR_ERR(inode);
+	if (IS_ERR(inode))
+		goto out_dir;
+
+	inode->i_op = &exofs_dir_inode_operations;
+	inode->i_fop = &exofs_dir_operations;
+	inode->i_mapping->a_ops = &exofs_aops;
+
+	inode_inc_link_count(inode);
+
+	err = exofs_make_empty(inode, dir);
+	if (err)
+		goto out_fail;
+
+	err = exofs_add_link(dentry, inode);

fs/exofs/namei.c new file +5 -0

+	iput(inode);
+out_dir:
+	inode_dec_link_count(dir);
+	goto out;
+}

fs/exofs/super.c new file +30 -0

+static int parse_options(char *options, struct exofs_mountopt *opts)
+{
+	char *p;
+	substring_t args[MAX_OPT_ARGS];
+	int option;
+	bool s_pid = false;
+
+	EXOFS_DBGMSG("parse_options %s\n", options);
+	/* defaults */
+	memset(opts, 0, sizeof(*opts));
+	opts->timeout = BLK_DEFAULT_SG_TIMEOUT;
+
+	while ((p = strsep(&options, ",")) != NULL) {
+		int token;
+		char str[32];
+
+		if (!*p)
+			continue;
+
+		token = match_token(p, tokens, args);
+		switch (token) {
+		case Opt_pid:
+			if (0 == match_strlcpy(str, &args[0], sizeof(str)))
+				return -EINVAL;
+			opts->pid = simple_strtoull(str, NULL, 0);
+			if (opts->pid < EXOFS_MIN_PID) {
+				EXOFS_ERR("Partition ID must be >= %u",
+					  EXOFS_MIN_PID);
+				return -EINVAL;
+			}

fs/exofs/super.c new file +5 -0

+	if (!oi)
+		return NULL;
+
+	oi->vfs_inode.i_version = 1;
+	return &oi->vfs_inode;

fs/exofs/super.c new file +11 -0

+		wait_queue_head_t wq;
+		init_waitqueue_head(&wq);
+		wait_event_timeout(wq,
+				  (atomic_read(&sbi->s_curr_pending) == 0),
+				  msecs_to_jiffies(100));
+	}
+
+	osduld_put_device(sbi->s_dev);
+	kfree(sb->s_fs_info);
+	sb->s_fs_info = NULL;
+}

This patch includes osd infrastructure that will be used later by the file system.

Also the declarations of constants, on disk structures, and prototypes.

And the Kbuild+Kconfig files needed to build the exofs module.

Signed-off-by Boaz Harrosh <[email protected]>

---
 fs/exofs/Kbuild   |   30 +++++++
 fs/exofs/Kconfig  |   13 +++
 fs/exofs/common.h |  181 +++++++++++++++++++++++++++++++++++++++++
 fs/exofs/exofs.h  |  139 ++++++++++++++++++++++++++++++++
 fs/exofs/osd.c    |  230 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 593 insertions(+), 0 deletions(-)
 create mode 100644 fs/exofs/Kbuild
 create mode 100644 fs/exofs/Kconfig
 create mode 100644 fs/exofs/common.h
 create mode 100644 fs/exofs/exofs.h
 create mode 100644 fs/exofs/osd.c

fs/exofs/osd.c new file +21 -0

+static struct bio *_bio_map_pages(struct request_queue *req_q,
+				  struct page **pages, unsigned page_count,
+				  size_t length, gfp_t gfp_mask)
+{
+	struct bio *bio;
+	int i;
+
+	bio = bio_alloc(gfp_mask, page_count);
+	if (!bio) {
+		EXOFS_DBGMSG("Failed to bio_alloc page_count=%d\n", page_count);
+		return NULL;
+	}
+
+	for (i = 0; i < page_count && length; i++) {
+		size_t use_len = min(length, PAGE_SIZE);
+
+		if (use_len !=
+		    bio_add_pc_page(req_q, bio, pages[i], use_len, 0)) {
+			EXOFS_ERR("Failed bio_add_pc_page req_q=%p pages[i]=%p "
+				  "use_len=%Zd page_count=%d length=%Zd\n",
+				  req_q, pages[i], use_len, page_count, length);

fs/exofs/osd.c new file +67 -0

+int osd_req_read_pages(struct osd_request *or,
+	const struct osd_obj_id *obj, u64 offset, u64 length,
+	struct page **pages, int page_count)
+{
+	struct request_queue *req_q = or->osd_dev->scsi_device->request_queue;
+	struct bio *bio = _bio_map_pages(req_q, pages, page_count, length,
+					 GFP_KERNEL);
+
+	if (!bio)
+		return -ENOMEM;
+
+	_osd_read(or, obj, offset, bio);
+	return 0;
+}
+#endif /* def __KERNEL__ */
+
+int osd_req_read_kern(struct osd_request *or,
+	const struct osd_obj_id *obj, u64 offset, void* buff, u64 len)
+{
+	struct request_queue *req_q = or->osd_dev->scsi_device->request_queue;
+	struct bio *bio = bio_map_kern(req_q, buff, len, GFP_KERNEL);
+
+	if (!bio)
+		return -ENOMEM;
+
+	_osd_read(or, obj, offset, bio);
+	return 0;
+}
+
+static void _osd_write(struct osd_request *or,
+	const struct osd_obj_id *obj, uint64_t offset, struct bio *bio)
+{
+	osd_req_write(or, obj, bio, offset);
+	EXOFS_DBGMSG("osd_req_write(p=%llX, ob=%llX, l=%llu, of=%llu)\n",
+		_LLU(obj->partition), _LLU(obj->id), _LLU(bio->bi_size),
+		_LLU(offset));
+}
+
+#ifdef __KERNEL__
+int osd_req_write_pages(struct osd_request *or,
+	const struct osd_obj_id *obj, u64 offset, u64 length,
+	struct page **pages, int page_count)
+{
+	struct request_queue *req_q = or->osd_dev->scsi_device->request_queue;
+	struct bio *bio = _bio_map_pages(req_q, pages, page_count, length,
+					 GFP_KERNEL);
+
+	if (!bio)
+		return -ENOMEM;
+
+	_osd_write(or, obj, offset, bio);
+	return 0;
+}
+#endif /* def __KERNEL__ */
+
+int osd_req_write_kern(struct osd_request *or,
+	const struct osd_obj_id *obj, u64 offset, void* buff, u64 len)
+{
+	struct request_queue *req_q = or->osd_dev->scsi_device->request_queue;
+	struct bio *bio = bio_map_kern(req_q, buff, len, GFP_KERNEL);
+
+	if (!bio)
+		return -ENOMEM;
+
+	_osd_write(or, obj, offset, bio);
+	return 0;
+}

Signature · 7 lines

1.6.0.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quoted 21 lines · On Mon, 9 Feb 2009 15:12:09 +0200 Boaz Harrosh <[email protected]> wrote:

This patch includes osd infrastructure that will be used later by the file system.

Also the declarations of constants, on disk structures, and prototypes.

And the Kbuild+Kconfig files needed to build the exofs module.

Signed-off-by Boaz Harrosh <[email protected]>

---
 fs/exofs/Kbuild   |   30 +++++++
 fs/exofs/Kconfig  |   13 +++
 fs/exofs/common.h |  181 +++++++++++++++++++++++++++++++++++++++++
 fs/exofs/exofs.h  |  139 ++++++++++++++++++++++++++++++++
 fs/exofs/osd.c    |  230 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 593 insertions(+), 0 deletions(-)
 create mode 100644 fs/exofs/Kbuild
 create mode 100644 fs/exofs/Kconfig
 create mode 100644 fs/exofs/common.h
 create mode 100644 fs/exofs/exofs.h
 create mode 100644 fs/exofs/osd.c

fs/exofs/osd.c line 131

Quoted 10 lines

fs/exofs/osd.c new file +10 -0

+static void _osd_read(struct osd_request *or,
+	const struct osd_obj_id *obj, uint64_t offset, struct bio *bio)
+{
+	osd_req_read(or, obj, bio, offset);
+	EXOFS_DBGMSG("osd_req_read(p=%llX, ob=%llX, l=%llu, of=%llu)\n",
+		_LLU(obj->partition), _LLU(obj->id), _LLU(bio->bi_size),
+		_LLU(offset));
+}
+
+#ifdef __KERNEL__

Hmm?

Quoted 21 lines

fs/exofs/osd.c new file +21 -0

+static struct bio *_bio_map_pages(struct request_queue *req_q,
+				  struct page **pages, unsigned page_count,
+				  size_t length, gfp_t gfp_mask)
+{
+	struct bio *bio;
+	int i;
+
+	bio = bio_alloc(gfp_mask, page_count);
+	if (!bio) {
+		EXOFS_DBGMSG("Failed to bio_alloc page_count=%d\n", page_count);
+		return NULL;
+	}
+
+	for (i = 0; i < page_count && length; i++) {
+		size_t use_len = min(length, PAGE_SIZE);
+
+		if (use_len !=
+		    bio_add_pc_page(req_q, bio, pages[i], use_len, 0)) {
+			EXOFS_ERR("Failed bio_add_pc_page req_q=%p pages[i]=%p "
+				  "use_len=%Zd page_count=%d length=%Zd\n",
+				  req_q, pages[i], use_len, page_count, length);

fs/exofs/osd.c line 162

Quoted 10 lines

fs/exofs/osd.c new file +10 -0

+			bio_put(bio);
+			return NULL;
+		}
+
+		length -= use_len;
+	}
+
+	WARN_ON(length);
+	return bio;
+}

1) exofs builds bios by hand.
2) exofs passes bio to OSD SCSI ULD.

As a result, exofs and OSD SCSI ULD need to know the internal of bio, that is, you reinvent the bio handling infrastructure, as pointed out in another thread in scsi-ml.

_bio_map_pages is called where the VFS passes an array of a pointer to a page frame.

Why can't you simply pass the array to OSD SCSI ULD? Then OSD SCSI ULD can use the block layer helper functions to build a request out of pages without knowing the internal of bio.

Quoted 25 lines · FUJITA Tomonori

Quoted 21 lines · On Mon, 9 Feb 2009 15:12:09 +0200 Boaz Harrosh <[email protected]> wrote:

This patch includes osd infrastructure that will be used later by the file system.

Also the declarations of constants, on disk structures, and prototypes.

And the Kbuild+Kconfig files needed to build the exofs module.

Signed-off-by Boaz Harrosh <[email protected]>

---
 fs/exofs/Kbuild   |   30 +++++++
 fs/exofs/Kconfig  |   13 +++
 fs/exofs/common.h |  181 +++++++++++++++++++++++++++++++++++++++++
 fs/exofs/exofs.h  |  139 ++++++++++++++++++++++++++++++++
 fs/exofs/osd.c    |  230 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 593 insertions(+), 0 deletions(-)
 create mode 100644 fs/exofs/Kbuild
 create mode 100644 fs/exofs/Kconfig
 create mode 100644 fs/exofs/common.h
 create mode 100644 fs/exofs/exofs.h
 create mode 100644 fs/exofs/osd.c

Quoted 13 lines

fs/exofs/osd.c line 131

Quoted 10 lines

fs/exofs/osd.c new file +10 -0

+static void _osd_read(struct osd_request *or,
+	const struct osd_obj_id *obj, uint64_t offset, struct bio *bio)
+{
+	osd_req_read(or, obj, bio, offset);
+	EXOFS_DBGMSG("osd_req_read(p=%llX, ob=%llX, l=%llu, of=%llu)\n",
+		_LLU(obj->partition), _LLU(obj->id), _LLU(bio->bi_size),
+		_LLU(offset));
+}
+
+#ifdef __KERNEL__

Hmm?

Yep, this file also complies in user mode.

Quoted 39 lines

Quoted 21 lines

fs/exofs/osd.c new file +21 -0

+static struct bio *_bio_map_pages(struct request_queue *req_q,
+				  struct page **pages, unsigned page_count,
+				  size_t length, gfp_t gfp_mask)
+{
+	struct bio *bio;
+	int i;
+
+	bio = bio_alloc(gfp_mask, page_count);
+	if (!bio) {
+		EXOFS_DBGMSG("Failed to bio_alloc page_count=%d\n", page_count);
+		return NULL;
+	}
+
+	for (i = 0; i < page_count && length; i++) {
+		size_t use_len = min(length, PAGE_SIZE);
+
+		if (use_len !=
+		    bio_add_pc_page(req_q, bio, pages[i], use_len, 0)) {
+			EXOFS_ERR("Failed bio_add_pc_page req_q=%p pages[i]=%p "
+				  "use_len=%Zd page_count=%d length=%Zd\n",
+				  req_q, pages[i], use_len, page_count, length);

fs/exofs/osd.c line 162

Quoted 10 lines

fs/exofs/osd.c new file +10 -0

+			bio_put(bio);
+			return NULL;
+		}
+
+		length -= use_len;
+	}
+
+	WARN_ON(length);
+	return bio;
+}

1) exofs builds bios by hand.
2) exofs passes bio to OSD SCSI ULD.

As a result, exofs and OSD SCSI ULD need to know the internal of bio, that is, you reinvent the bio handling infrastructure, as pointed out in another thread in scsi-ml.

Quoted 8 lines

_bio_map_pages is called where the VFS passes an array of a pointer to a page frame.

Why can't you simply pass the array to OSD SCSI ULD? Then OSD SCSI ULD can use the block layer helper functions to build a request out of pages without knowing the internal of bio.

Because actually this code is wrong and temporary and will change soon. At vfs write_pages I do not get a linear array of page pointers but a link-list of pages. This will not fit any current model.

Also looking
ahead I will have RAID 0, 1, 5, and 6 on objects of different devices. bio is the perfect collector for memory information in this situation.

exofs is not the first and only file system who is using bios. Proof of the matter is that block exports a bio submit routine.

As I said on the other thread, I could live without it for now, for a short while, but I will regret it badly and it will hurt performance in the long run.

<snip>

Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 37 lines · On Mon, 16 Feb 2009 10:49:39 +0200 Boaz Harrosh <[email protected]> wrote:

Quoted 27 lines · FUJITA Tomonori

Quoted 24 lines · On Mon, 9 Feb 2009 15:12:09 +0200 Boaz Harrosh <[email protected]> wrote:

This patch includes osd infrastructure that will be used later by the file system.

Also the declarations of constants, on disk structures, and prototypes.

And the Kbuild+Kconfig files needed to build the exofs module.

Signed-off-by Boaz Harrosh <[email protected]>

---
 fs/exofs/Kbuild   |   30 +++++++
 fs/exofs/Kconfig  |   13 +++
 fs/exofs/common.h |  181 +++++++++++++++++++++++++++++++++++++++++
 fs/exofs/exofs.h  |  139 ++++++++++++++++++++++++++++++++
 fs/exofs/osd.c    |  230 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 593 insertions(+), 0 deletions(-)
 create mode 100644 fs/exofs/Kbuild
 create mode 100644 fs/exofs/Kconfig
 create mode 100644 fs/exofs/common.h
 create mode 100644 fs/exofs/exofs.h
 create mode 100644 fs/exofs/osd.c

fs/exofs/osd.c new file +3 -0

+static void _osd_read(struct osd_request *or,
+	const struct osd_obj_id *obj, uint64_t offset, struct bio *bio)
+{

Quoted 9 lines

fs/exofs/osd.c line 131

Quoted 7 lines

fs/exofs/osd.c new file +7 -0

+	osd_req_read(or, obj, bio, offset);
+	EXOFS_DBGMSG("osd_req_read(p=%llX, ob=%llX, l=%llu, of=%llu)\n",
+		_LLU(obj->partition), _LLU(obj->id), _LLU(bio->bi_size),
+		_LLU(offset));
+}
+
+#ifdef __KERNEL__

Hmm?

Quoted 1 line

Yep, this file also complies in user mode.

Even if you do, it's a good thing to add __KERNEL__ to fs/*.c?

Quoted 46 lines

Quoted 46 lines

Quoted 21 lines

fs/exofs/osd.c new file +21 -0

+static struct bio *_bio_map_pages(struct request_queue *req_q,
+				  struct page **pages, unsigned page_count,
+				  size_t length, gfp_t gfp_mask)
+{
+	struct bio *bio;
+	int i;
+
+	bio = bio_alloc(gfp_mask, page_count);
+	if (!bio) {
+		EXOFS_DBGMSG("Failed to bio_alloc page_count=%d\n", page_count);
+		return NULL;
+	}
+
+	for (i = 0; i < page_count && length; i++) {
+		size_t use_len = min(length, PAGE_SIZE);
+
+		if (use_len !=
+		    bio_add_pc_page(req_q, bio, pages[i], use_len, 0)) {
+			EXOFS_ERR("Failed bio_add_pc_page req_q=%p pages[i]=%p "
+				  "use_len=%Zd page_count=%d length=%Zd\n",
+				  req_q, pages[i], use_len, page_count, length);

fs/exofs/osd.c line 162

Quoted 10 lines

fs/exofs/osd.c new file +10 -0

+			bio_put(bio);
+			return NULL;
+		}
+
+		length -= use_len;
+	}
+
+	WARN_ON(length);
+	return bio;
+}

1) exofs builds bios by hand.
2) exofs passes bio to OSD SCSI ULD.

As a result, exofs and OSD SCSI ULD need to know the internal of bio, that is, you reinvent the bio handling infrastructure, as pointed out in another thread in scsi-ml.

_bio_map_pages is called where the VFS passes an array of a pointer to a page frame.

Why can't you simply pass the array to OSD SCSI ULD? Then OSD SCSI ULD can use the block layer helper functions to build a request out of pages without knowing the internal of bio.

Quoted 3 lines

Because actually this code is wrong and temporary and will change soon. At vfs write_pages I do not get a linear array of page pointers but a link-list of pages. This will not fit any current model.

Then, why can't you pass a link-list of pages?

Quoted 4 lines

Also looking
ahead I will have RAID 0, 1, 5, and 6 on objects of different devices. bio is the perfect collector for memory information in this situation.

You will add such features to exofs, handling multiple devices internally?

Quoted 3 lines

exofs is not the first and only file system who is using bios. Proof of the matter is that block exports a bio submit routine.

Seems that exofs just passes pages and the ULD sends a SCSI command including these pages. I don't see how exofs needs to handle bio directly.

Quoted 7 lines

As I said on the other thread, I could live without it for now, for a short while, but I will regret it badly and it will hurt performance in the long run.

<snip>

Boaz

Quoted 7 lines · FUJITA Tomonori

Quoted 3 lines · Boaz Harrosh

Also looking
ahead I will have RAID 0, 1, 5, and 6 on objects of different devices. bio is the perfect collector for memory information in this situation.

You will add such features to exofs, handling multiple devices internally?

Multiple objects on Multiple devices, Yes.

Hi.

On Mon, Feb 09, 2009 at 03:24:13PM +0200, Boaz Harrosh ([email protected]) wrote:

fs/exofs/dir.c line 408

Quoted 12 lines

fs/exofs/dir.c new file +12 -0

+void exofs_set_link(struct inode *dir, struct exofs_dir_entry *de,
+			struct page *page, struct inode *inode)
+{
+	loff_t pos = page_offset(page) +
+			(char *) de - (char *) page_address(page);
+	unsigned len = le16_to_cpu(de->rec_len);
+	int err;
+
+	lock_page(page);
+	err = exofs_write_begin(NULL, page->mapping, pos, len,
+				AOP_FLAG_UNINTERRUPTIBLE, &page, NULL);
+	BUG_ON(err);

How unfriendly :)
simple_write_begin() may fail if there is no memory or appropriate cgroup does not allow to charge more memory.

fs/exofs/dir.c line 476

Quoted 6 lines

fs/exofs/dir.c new file +6 -0

+		unlock_page(page);
+		exofs_put_page(page);
+	}
+	BUG();
+	return -EINVAL;
+

So it will crash the system if directory entry does not contain any data? What was wrong with -EINVAL?

Also, dir_pages(), readpage_done() and similar functions scream for less generic names, and at least dir_pages() is already implemented in another 5 filesystems.

Quoted 8 lines

fs/exofs/dir.c new file +8 -0

+int exofs_delete_entry(struct exofs_dir_entry *dir, struct page *page)
+{
+	struct address_space *mapping = page->mapping;
+	struct inode *inode = mapping->host;
+	struct exofs_sb_info *sbi = inode->i_sb->s_fs_info;
+	char *kaddr = page_address(page);
+	unsigned from = ((char *)dir - kaddr) & ~(exofs_chunk_size(inode)-1);
+	unsigned to = ((char *)dir - kaddr) + le16_to_cpu(dir->rec_len);

fs/exofs/dir.c line 522

Quoted 6 lines

fs/exofs/dir.c new file +6 -0

+	loff_t pos;
+	struct exofs_dir_entry *pde = NULL;
+	struct exofs_dir_entry *de = (struct exofs_dir_entry *) (kaddr + from);
+	int err;
+
+	while ((char *)de < (char *)dir) {

They have the same type, why is it needed to cast them to char pointer?

Quoted 11 lines

fs/exofs/dir.c new file +11 -0

+		if (de->rec_len == 0) {
+			EXOFS_ERR("ERROR: exofs_delete_entry:"
+				"zero-length directory entry");
+			err = -EIO;
+			goto out;
+		}
+		pde = de;
+		de = exofs_next_entry(de);
+	}
+	if (pde)
+		from = (char *)pde - (char *)page_address(page);

fs/exofs/dir.c line 538

Quoted 5 lines

fs/exofs/dir.c new file +5 -0

+	pos = page_offset(page) + from;
+	lock_page(page);
+	err = exofs_write_begin(NULL, page->mapping, pos, to - from, 0,
+							&page, NULL);
+	BUG_ON(err);

Ugh, in the exofs_make_empty() it is handled without so visible pain.

Quoted 11 lines

fs/exofs/dir.c new file +11 -0

+	if (pde)
+		pde->rec_len = cpu_to_le16(to - from);
+	dir->inode_no = 0;
+	err = exofs_commit_chunk(page, pos, to - from);
+	inode->i_ctime = inode->i_mtime = CURRENT_TIME;
+	mark_inode_dirty(inode);
+	sbi->s_numfiles--;
+out:
+	exofs_put_page(page);
+	return err;
+}

fs/exofs/inode.c int exofs_setattr(struct dentry *dentry, struct iattr *iattr) · line 735

Quoted 6 lines

fs/exofs/inode.c +6 -0

+
+	atomic_inc(&inode->i_count);
+
+	ret = exofs_async_op(or, create_done, inode, oi->i_cred);
+	if (ret) {
+		atomic_dec(&inode->i_count);

igrab()/iput()?

Quoted 39 lines

fs/exofs/namei.c new file +38 -0

+		osd_end_request(or);
+		return ERR_PTR(-EIO);
+	}
+	atomic_inc(&sbi->s_curr_pending);
+
+	return inode;
+}
 
+static int exofs_mkdir(struct inode *dir, struct dentry *dentry, int mode)
+{
+	struct inode *inode;
+	int err = -EMLINK;
+
+	if (dir->i_nlink >= EXOFS_LINK_MAX)
+		goto out;
+
+	inode_inc_link_count(dir);
+
+	inode = exofs_new_inode(dir, S_IFDIR | mode);
+	err = PTR_ERR(inode);
+	if (IS_ERR(inode))
+		goto out_dir;
+
+	inode->i_op = &exofs_dir_inode_operations;
+	inode->i_fop = &exofs_dir_operations;
+	inode->i_mapping->a_ops = &exofs_aops;
+
+	inode_inc_link_count(inode);
+
+	err = exofs_make_empty(inode, dir);
+	if (err)
+		goto out_fail;
+
+	err = exofs_add_link(dentry, inode);
+	if (err)
+		goto out_fail;
+
+	d_instantiate(dentry, inode);
+out:

fs/exofs/namei.c line 197

Quoted 5 lines

fs/exofs/namei.c new file +5 -0

+	return err;
+
+out_fail:
+	inode_dec_link_count(inode);
+	inode_dec_link_count(inode);

Why two decrements, will it be ok after exofs_make_empty() fail when it was incremented only once?

fs/exofs/namei.c line 203

Quoted 5 lines

fs/exofs/namei.c new file +5 -0

+	iput(inode);
+out_dir:
+	inode_dec_link_count(dir);
+	goto out;
+}

Quoted 7 lines

Quoted 3 lines

Also looking
ahead I will have RAID 0, 1, 5, and 6 on objects of different devices. bio is the perfect collector for memory information in this situation.

You will add such features to exofs, handling multiple devices internally?

Multiple objects on Multiple devices, Yes.

Quoted 7 lines

Quoted 2 lines

exofs is not the first and only file system who is using bios. Proof of the matter is that block exports a bio submit routine.

Seems that exofs just passes pages and the ULD sends a SCSI command including these pages. I don't see how exofs needs to handle bio directly.

How do you propose to collect these pages? and keep them without allocating an extra list? without pre-allocating a struct request? and without re-inventing the bio structure?

Hi.

fs/exofs/super.c line 106

Quoted 8 lines

fs/exofs/super.c new file +8 -0

+		case Opt_to:
+			if (match_int(&args[0], &option))
+				return -EINVAL;
+			if (option <= 0) {
+				EXOFS_ERR("Timout must be > 0");
+				return -EINVAL;
+			}
+			opts->timeout = option * HZ;

Is it intentional to be a different timeouton systems with different HX but the same mount option?

fs/exofs/super.c line 136

Quoted 5 lines

fs/exofs/super.c new file +5 -0

+static struct inode *exofs_alloc_inode(struct super_block *sb)
+{
+	struct exofs_i_info *oi;
+
+	oi = kmem_cache_alloc(exofs_inode_cachep, GFP_KERNEL);

I'm curious if this should be GFP_NOFS or not?

Quoted 5 lines

fs/exofs/super.c new file +5 -0

+	if (!oi)
+		return NULL;
+
+	oi->vfs_inode.i_version = 1;
+	return &oi->vfs_inode;

fs/exofs/super.c

Quoted 10 lines

fs/exofs/super.c new file +9 -0

+}
 
+static void exofs_put_super(struct super_block *sb)
+{
+	int num_pend;
+	struct exofs_sb_info *sbi = sb->s_fs_info;
+
+	/* make sure there are no pending commands */
+	for (num_pend = atomic_read(&sbi->s_curr_pending); num_pend > 0;
+	     num_pend = atomic_read(&sbi->s_curr_pending)) {

This rises a question. Let's check exofs_new_inode() for example (it is a bad example, since inode can not be created when we already in the put_super() callback, but still there are others), it increments s_curr_pending way after inode was created, so is it possible that some in-flight callback is about to be executed and its subsequent s_curr_pending manipulation will not be detected by this loop?

Should s_curr_pending increment be audited all over the code to be increased before the potential postponing command starts (which is not the case in exofs_new_inode() above)?

fs/exofs/super.c line 262

Quoted 11 lines

fs/exofs/super.c new file +11 -0

+		wait_queue_head_t wq;
+		init_waitqueue_head(&wq);
+		wait_event_timeout(wq,
+				  (atomic_read(&sbi->s_curr_pending) == 0),
+				  msecs_to_jiffies(100));
+	}
+
+	osduld_put_device(sbi->s_dev);
+	kfree(sb->s_fs_info);
+	sb->s_fs_info = NULL;
+}

Quoted 8 lines · Boaz Harrosh

Quoted 7 lines · FUJITA Tomonori

Quoted 3 lines · Boaz Harrosh

Also looking
ahead I will have RAID 0, 1, 5, and 6 on objects of different devices. bio is the perfect collector for memory information in this situation.

You will add such features to exofs, handling multiple devices internally?

Quoted 1 line

Multiple objects on Multiple devices, Yes.

That sort of feature does not belong in exofs, but somewhat separate. Ideally we should be able to share "MD for OSD" with other OSD filesystems, and the "osdblk" device that I will produce once libosd hits upstream.

Jeff

Quoted 6 lines · On Mon, 16 Feb 2009 11:19:21 +0200 Boaz Harrosh <[email protected]> wrote:

Quoted 6 lines

Quoted 3 lines

Also looking
ahead I will have RAID 0, 1, 5, and 6 on objects of different devices. bio is the perfect collector for memory information in this situation.

You will add such features to exofs, handling multiple devices internally?

Quoted 1 line

Multiple objects on Multiple devices, Yes.

I thought that exofs is kinda example (reference) file system.

Nobody has seen your code. Let's discuss when we have the code. Over-designing for what we've not seen is not a good idea.

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

exofs is not the first and only file system who is using bios. Proof of the matter is that block exports a bio submit routine.

Seems that exofs just passes pages and the ULD sends a SCSI command including these pages. I don't see how exofs needs to handle bio directly.

Quoted 3 lines

How do you propose to collect these pages? and keep them without allocating an extra list? without pre-allocating a struct request? and without re-inventing the bio structure?

I don't think that allocating an extra list (or something) to keep them hurts performance. We can talk about it when you have the real performance results.

No can do. exofs is meant to be a reference implementation of a pNFS-objects file serving system. Have you read the spec of pNFS-objects layout? they define RAID 0, 1, 5, and 6. In pNFS the MDS is suppose to be able to write the data for its clients as NFS, so it needs to have all the infra structure and knowledge of an Client pNFS-object layout drive.

Quoted 5 lines · Boaz Harrosh

No can do. exofs is meant to be a reference implementation of a pNFS-objects file serving system. Have you read the spec of pNFS-objects layout? they define RAID 0, 1, 5, and 6. In pNFS the MDS is suppose to be able to write the data for its clients as NFS, so it needs to have all the infra structure and knowledge of an Client pNFS-object layout drive.

Yes, I have studied pNFS! I plan to add v4.1 and pNFS support to my NFS server, once v4.0 support is working well.

pNFS The Theory: is wise and necessary: permit clients to directly
connect to data storage, rather than copying through the metadata server(s). This is what every distributed filesystem is doing these days -- direct to data server for bulk data read/write.

pNFS The Specification: is an utter piece of shit. I can only presume
some shady backroom deal in a smoke-filled room was the reason this saw the light of day.

In a sane world, NFS clients would speak... NFS.

In the crazy world of pNFS, NFS clients are now forced to speak NFS, SCSI, RAID, and any number of proprietary layout types. When will HTTP be added to the list? :)

But anything beyond the NFS protocol for talking client <-> data servers is code bloat complexity madness for an NFS client that wishes to be compatible with "most of the NFS 4.1 world".

An ideal NFS client for pNFS should be asked to do these two things, and nothing more:

1) send metadata transactions to one or more metadata servers, using well-known NFS protocol

2) send data to one or more data servers, using well-known NFS protocol subset designed for storage (v4.1, section 13.6)

But no.

pNFS has forced a huge complexity on the NFS client, by permitting an unbounded number of network protocols. A "layout plugin" layer is required. SCSI and OSD support are REQUIRED for any reasonably compatible setup going forward.

But even more than the technical complexity, this is the first time in NFS history that NFS has required a protocol besides... NFS.

pNFS means that a useful. compatible NFS client must know all these storage protocols, in addition to NFS.

Furthermore, enabling proprietary layout types means that it is easy for a "compatible" v4.1 client to be denied parallel access to data available to other "compatible" v4.1 clients:

Client A: Linux, fully open source

Client B: Linux, with closed source module for
layout type SuperWhizBang storage

Both Client A and Client B can claim to be NFS v4.1 and pNFS compatible,
yet Client A must read data through the metadata server because it lacks the SuperWhizBang storage plugin.

pNFS means a never-ending arms race for the best storage layout, where NFS clients are inevitably compatibly with a __random subset__ of total available layout types. pNFS will be a continuing train wreck of fly-by-night storage companies, and their pet layout types & storage protocols.

It is a support nightmare, an admin nightmare, a firewall nightmare, a client implementor's nightmare, but a storage vendor's wet dream.

NFS was never beautiful, but at least until v4.0 it was well known and widely cross-compatible. And only required one network protocol: NFS.

Jeff

Quoted 5 lines · Boaz Harrosh

No can do. exofs is meant to be a reference implementation of a pNFS-objects file serving system. Have you read the spec of pNFS-objects layout? they define RAID 0, 1, 5, and 6. In pNFS the MDS is suppose to be able to write the data for its clients as NFS, so it needs to have all the infra structure and knowledge of an Client pNFS-object layout drive.

Yes, I have studied pNFS! I plan to add v4.1 and pNFS support to my NFS server, once v4.0 support is working well.

pNFS The Theory: is wise and necessary: permit clients to directly
connect to data storage, rather than copying through the metadata server(s). This is what every distributed filesystem is doing these days -- direct to data server for bulk data read/write.

pNFS The Specification: is an utter piece of shit. I can only presume
some shady backroom deal in a smoke-filled room was the reason this saw the light of day.

In a sane world, NFS clients would speak... NFS.

In the crazy world of pNFS, NFS clients are now forced to speak NFS, SCSI, RAID, and any number of proprietary layout types. When will HTTP be added to the list? :)

Quoted 5 lines · Boaz Harrosh

No can do. exofs is meant to be a reference implementation of a pNFS-objects file serving system. Have you read the spec of pNFS-objects layout? they define RAID 0, 1, 5, and 6. In pNFS the MDS is suppose to be able to write the data for its clients as NFS, so it needs to have all the infra structure and knowledge of an Client pNFS-object layout drive.

Yes, I have studied pNFS! I plan to add v4.1 and pNFS support to my NFS server, once v4.0 support is working well.

pNFS The Theory: is wise and necessary: permit clients to directly
connect to data storage, rather than copying through the metadata server(s). This is what every distributed filesystem is doing these days -- direct to data server for bulk data read/write.

pNFS The Specification: is an utter piece of shit. I can only presume
some shady backroom deal in a smoke-filled room was the reason this saw the light of day.

In a sane world, NFS clients would speak... NFS.

In the crazy world of pNFS, NFS clients are now forced to speak NFS, SCSI, RAID, and any number of proprietary layout types. When will HTTP be added to the list? :)

But anything beyond the NFS protocol for talking client <-> data servers is code bloat complexity madness for an NFS client that wishes to be compatible with "most of the NFS 4.1 world".

An ideal NFS client for pNFS should be asked to do these two things, and nothing more:

1) send metadata transactions to one or more metadata servers, using well-known NFS protocol

2) send data to one or more data servers, using well-known NFS protocol subset designed for storage (v4.1, section 13.6)

But no.

pNFS has forced a huge complexity on the NFS client, by permitting an unbounded number of network protocols. A "layout plugin" layer is required. SCSI and OSD support are REQUIRED for any reasonably compatible setup going forward.

But even more than the technical complexity, this is the first time in NFS history that NFS has required a protocol besides... NFS.

pNFS means that a useful. compatible NFS client must know all these storage protocols, in addition to NFS.

Furthermore, enabling proprietary layout types means that it is easy for a "compatible" v4.1 client to be denied parallel access to data available to other "compatible" v4.1 clients:

Client A: Linux, fully open source

Client B: Linux, with closed source module for
layout type SuperWhizBang storage

Both Client A and Client B can claim to be NFS v4.1 and pNFS compatible,
yet Client A must read data through the metadata server because it lacks the SuperWhizBang storage plugin.

pNFS means a never-ending arms race for the best storage layout, where NFS clients are inevitably compatibly with a __random subset__ of total available layout types. pNFS will be a continuing train wreck of fly-by-night storage companies, and their pet layout types & storage protocols.

It is a support nightmare, an admin nightmare, a firewall nightmare, a client implementor's nightmare, but a storage vendor's wet dream.

NFS was never beautiful, but at least until v4.0 it was well known and widely cross-compatible. And only required one network protocol: NFS.

Jeff

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 20 lines · Jeff Garzik

Quoted 5 lines · Boaz Harrosh

No can do. exofs is meant to be a reference implementation of a pNFS-objects file serving system. Have you read the spec of pNFS-objects layout? they define RAID 0, 1, 5, and 6. In pNFS the MDS is suppose to be able to write the data for its clients as NFS, so it needs to have all the infra structure and knowledge of an Client pNFS-object layout drive.

Yes, I have studied pNFS! I plan to add v4.1 and pNFS support to my NFS server, once v4.0 support is working well.

pNFS The Theory: is wise and necessary: permit clients to directly
connect to data storage, rather than copying through the metadata server(s). This is what every distributed filesystem is doing these days -- direct to data server for bulk data read/write.

pNFS The Specification: is an utter piece of shit. I can only presume
some shady backroom deal in a smoke-filled room was the reason this saw the light of day.

Quoted 5 lines

In a sane world, NFS clients would speak... NFS.

In the crazy world of pNFS, NFS clients are now forced to speak NFS, SCSI, RAID, and any number of proprietary layout types. When will HTTP be added to the list? :)

Heh, it's one of the endearing faults of the storage industry that we never learn from our mistakes ... particularly in storage protocols.

Actually, perhaps that's a mischaracterised: we never actually learn from our successes. For example, most popular storage protocols solve about 80% of the problem (NFSv2) get something bolted on to take that to 95% (locking) and rule for decades. We end up obsessing about the 5% and produce something that's like 10x the overhead to solve it. Customers, for some unfathomable reason, hate complexity (I suspect principally because it in some measure equals expense) so the 100% solution (which actually turns out to be a 95% one because the over engineered complexity adds another 5% of different problems that take years to find) tends to work its way into a niche and stay there ... eventually fading.

If you're really lucky, the niche evolves into something sustainable. For example iSCSI: blew its early promise, pulled a bunch of unnecessary networking into the protocol and ended up too big to fit in disk firmware (thus destroying the ability to have a simple network tap to replace storage fabric). It's been slowly fading until Virtualisation came along. Now all the other solutions to getting storage into virtual machines are so horrible and arcane that iSCSI looks like a winner (if the alternative is Frankenstein's monster, Grendel's mother suddenly looks more attractive as a partner).

So, trust the customer ... if it's so horrible it shouldn't have seen the light of day, the chances are that no-one will buy it anyway.

James

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

exofs is not the first and only file system who is using bios. Proof of the matter is that block exports a bio submit routine.

Seems that exofs just passes pages and the ULD sends a SCSI command including these pages. I don't see how exofs needs to handle bio directly.

Quoted 7 lines

Quoted 3 lines

How do you propose to collect these pages? and keep them without allocating an extra list? without pre-allocating a struct request? and without re-inventing the bio structure?

I don't think that allocating an extra list (or something) to keep them hurts performance. We can talk about it when you have the real performance results.

So you are the one that starts to invent the wheel here. I thought I was the one that does that, only you only called me by names, because you never showed me where.

But please only answer one question for me: Please don't write back if you do not answer this question:

Why do other filesystems allow to use bios? are they going to stop? Who is going to remove that?

Can you stop the argument, "exofs is similar to the existing traditional file systems hence it should be treated equally". It's simply untrue. Does anyone except for panasas people insist the same argument?

We are talking about the design of exofs, which also affects the design of OSD ULD (including the library) living in SCSI mid-layer.

It's something completely different from existing traditional file systems that work nicely on the top of the block layer.

As discussed in another thread, now OSD ULD reinvents the bio handling infrastructure because of the design of exofs.

But OSD ULD can use the
block layer helper functions to avoid the re-invention if we change the exofs design to take pages instead of bios.

For now, it works

perfectly for exofs. In the future, we might change it but we don't know until you submit patches (or the performance results) that show taking pages doesn't work for exofs nicely.

I guess that we need to evolve the block layer to support OSD stuff cleanly than we've discussed recently. But again we can do when we definitely need to do.

Quoted 6 lines · FUJITA Tomonori

Can you stop the argument, "exofs is similar to the existing traditional file systems hence it should be treated equally". It's simply untrue. Does anyone except for panasas people insist the same argument?

No I will not, it is true. exofs is just a regular old filesystem nothing different.

Quoted 8 lines · On Tue, 17 Feb 2009 10:10:15 +0200 Boaz Harrosh <[email protected]> wrote:

Quoted 5 lines · FUJITA Tomonori

Can you stop the argument, "exofs is similar to the existing traditional file systems hence it should be treated equally". It's simply untrue. Does anyone except for panasas people insist the same argument?

No I will not, it is true. exofs is just a regular old filesystem nothing different.

After reading this, I gave up discussing this issue with you but I still wait for your fixes that you promised:

http://marc.info/?l=linux-scsi&m=123445759718253&w=2

Thanks,
--

Quoted 4 lines · Evgeniy Polyakov

Hi.

On Mon, Feb 09, 2009 at 03:24:13PM +0200, Boaz Harrosh ([email protected]) wrote:

<snip>

Quoted 8 lines

fs/exofs/inode.c int exofs_setattr(struct dentry *dentry, struct iattr *iattr) · line 735

Quoted 6 lines

fs/exofs/inode.c +6 -0

+
+	atomic_inc(&inode->i_count);
+
+	ret = exofs_async_op(or, create_done, inode, oi->i_cred);
+	if (ret) {
+		atomic_dec(&inode->i_count);

igrab()/iput()?

Thanks, makes much more sense. Sorry leftovers from 2.6.10

Quoted 37 lines

Quoted 37 lines

fs/exofs/namei.c new file +37 -0

+		osd_end_request(or);
+		return ERR_PTR(-EIO);
+	}
+	atomic_inc(&sbi->s_curr_pending);
+
+	return inode;
+}
+static int exofs_mkdir(struct inode *dir, struct dentry *dentry, int mode)
+{
+	struct inode *inode;
+	int err = -EMLINK;
+
+	if (dir->i_nlink >= EXOFS_LINK_MAX)
+		goto out;
+
+	inode_inc_link_count(dir);
+
+	inode = exofs_new_inode(dir, S_IFDIR | mode);
+	err = PTR_ERR(inode);
+	if (IS_ERR(inode))
+		goto out_dir;
+
+	inode->i_op = &exofs_dir_inode_operations;
+	inode->i_fop = &exofs_dir_operations;
+	inode->i_mapping->a_ops = &exofs_aops;
+
+	inode_inc_link_count(inode);
+
+	err = exofs_make_empty(inode, dir);
+	if (err)
+		goto out_fail;
+
+	err = exofs_add_link(dentry, inode);
+	if (err)
+		goto out_fail;
+
+	d_instantiate(dentry, inode);

Quoted 9 lines

fs/exofs/namei.c line 197

Quoted 6 lines

fs/exofs/namei.c new file +6 -0

+out:
+	return err;
+
+out_fail:
+	inode_dec_link_count(inode);
+	inode_dec_link_count(inode);

Why two decrements, will it be ok after exofs_make_empty() fail when it was incremented only once?

That's hard to say, I'll investigate it some more. Thanks

Quoted 8 lines

Quoted 7 lines

fs/exofs/inode.c int exofs_setattr(struct dentry *dentry, struct iattr *iattr) · line 735

Quoted 5 lines

fs/exofs/inode.c +5 -0

+	atomic_inc(&inode->i_count);
+
+	ret = exofs_async_op(or, create_done, inode, oi->i_cred);
+	if (ret) {
+		atomic_dec(&inode->i_count);

igrab()/iput()?

Quoted 2 lines

Thanks, makes much more sense. Sorry leftovers from 2.6.10

It's the same at ext2. I looked at the igrab()/iput() code it does some extra locks which I'm afraid of at this stage. I'll postpone this to the next (next) merge window, after I ran with it for a while.