search for: newdream

...have read / write permissions to /dev/tty with OpenSSH 3.4p1 on Linux, the error message given is "Host key verification failed"; this error message is misleading and confusing IMHO. dali% ssh -V OpenSSH_3.4p1 Debian 1:3.4p1-1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f dali% ssh jazz.hq.newdream.net Host key verification failed. dali% strace ssh jazz.hq.newdream.net [...] read(4, "jareth,jareth.dreamhost.com,66.3"..., 4096) = 251 read(4, "", 4096) = 0 close(4) = 0 munmap(0x124000, 4096) = 0 open(&quot...

* Sage Weil (sage@newdream.net) [091216 17:55]: > On Wed, 16 Dec 2009, Li Dongyang wrote: > > > Have a look at line 998, ioctl.c, inside btrfs_ioctl_clone(), > > the src->i_size(the size of the testfile created by touch) is just 0, and this > > will cause btrfs_ioctl_clone just return -EINVAL. &g...

.. it would be great if btrfs could be expended about abilities that OneFS file system has (FS by Isilon) .. there is ceph open source clustered/distributed storage system that is using btrfs, maybe work with those people would be a good start http://ceph.newdream.net/about/ http://ceph.newdream.net/ -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

...file, we will deadlock. If it''s the same file, this check means we won''t deadlock, but the transaction will be prematurely closed out. Any user transaction ioctl users should be careful to avoid fsync() and close out the transaction explicitly. Signed-off-by: Sage Weil <sage@newdream.net> --- fs/btrfs/file.c | 6 ------ 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index d146dde..2e6404f 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -1097,12 +1097,6 @@ int btrfs_sync_file(struct file *file, struct dentry *dentry,...

...pages for the clone ioctl target range or else we''ll confuse ourselves to no end. If the old data was cached, we''ll still see it (until remount). If it was dirty we''ll get a mix of old and new data if the page(s) are partially updated. Signed-off-by: Sage Weil <sage@newdream.net> --- fs/btrfs/ioctl.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index a3c4751..cac9491 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -2243,6 +2243,10 @@ static noinline long btrfs_ioctl_clone(struct file *file,...

2011/10/26 Sage Weil <sage@newdream.net>: > On Wed, 26 Oct 2011, Christian Brunner wrote: >> >> > Christian, have you tweaked those settings in your ceph.conf?  It would be >> >> > something like ''journal dio = false''.  If not, can you verify that >> >> > directio s...

Hi everyone, This patchset is the latest approach I''m using for the Ceph storage daemon to keep track of which data has safely committed to disk. The basic idea is to not use the (problematic) user transaction ioctls at all. Instead, the daemon quiesces its own write requests, initiates an async snapshot, and then continues. The snapshot approach is nice because it provides rollback.

Hi Chris, This is the extent of my current queue of Btrfs snapshot/subvol/commit stuff. Most of these were posted several months ago. Can be sent upstream during this merge window? Not having this functionality is becoming a bit of a roadblock for our efforts to keep the Ceph data in a consistent state. These patches are also available from

...ompleted file system operations). This was previously the behavior only when a snapshot is created. This is used by Ceph to ensure that completed writes make it to the platter along with the metadata operations they are bound to (by BTRFS_IOC_TRANS_{START,END}). Signed-off-by: Sage Weil <sage@newdream.net> --- fs/btrfs/ctree.h | 1 + fs/btrfs/super.c | 10 +++++++--- fs/btrfs/transaction.c | 5 ++++- 3 files changed, 12 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index 471fa67..019e7a7 100644 --- a/fs/btrfs/ctree.h +++ b/fs/btrfs/ctree....

...user address space individually so we''d either need two passes, a big kmalloc, or further trust the app to get the value right. (Same goes for the data size, actually, although that''s easier to get correct.) Thoughts on this? Thanks- sage Signed-off-by: Sage Weil <sage@newdream.net> --- fs/btrfs/ioctl.c | 187 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/btrfs/ioctl.h | 49 ++++++++++++++ fs/namei.c | 3 + fs/open.c | 2 + fs/read_write.c | 2 + fs/xattr.c | 2 + 6 files changed, 245 insertions(+), 0 deletions(-) diff -...

Add missing mnt_drop_write to match the mnt_want_write in btrfs_ioctl_trans_start. Signed-off-by: Sage Weil <sage@newdream.net> --- fs/btrfs/ioctl.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 6228b69..69c4a07 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -1059,6 +1059,8 @@ long btrfs_ioctl_trans_end(struct file *file) root->fs_i...

...nd of file (this is always the case with CLONE). It was then using that offset when extending the destination file''s i_size. Fix this by not setting i_size beyond the originally requested ending offset. This bug was introduced by a22285a6 (2.6.35-rc1). Signed-off-by: Sage Weil <sage@newdream.net> --- fs/btrfs/ioctl.c | 16 +++++++++++++--- 1 files changed, 13 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 4cdb98c..a687f28 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -1578,6 +1578,7 @@ static noinline long btrfs_ioctl_clone(struct...

...process (calling btrfs_end_transaction()) to decrement num_writers such that we wait forever instead of for 1. Fix this by deciding how long to wait when we wait. Include a smp_mb() before checking if the waitqueue is active to ensure the num_writers is visible. Signed-off-by: Sage Weil <sage@newdream.net> --- v2: - add smp_mb() before waitqueue_active() check to clone another possible race fs/btrfs/transaction.c | 13 +++++-------- 1 files changed, 5 insertions(+), 8 deletions(-) diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index 66e4c66..b461fe3 100644 --- a/fs/btrfs/t...

So after some problems with NFS and transaction logs getting corrupted. Im tyring out storing them localy. via.. mail_location: maildir:~/Maildir:INDEX=/var/dovecot/indexes/%u the problem is with a large amount of users.. the indexes dir becomes huge with this setup. So a change to make this better is... mail_location: maildir:~/Maildir:INDEX=/var/dovecot/indexes/%d/%n to seperate the users

After running ceph on XFS for some time, I decided to try btrfs again. Performance with the current "for-linux-min" branch and big metadata is much better. The only problem (?) I''m still seeing is a warning that seems to occur from time to time: [87703.784552] ------------[ cut here ]------------ [87703.789759] WARNING: at fs/btrfs/inode.c:2103

...l_rm_allowed that allows users to delete a (potentially non-empty!) subvol when they would otherwise we allowed to do an rmdir(2). We duplicate the may_delete() checks from the core VFS code to implement identical security checks (minus the directory size check). Signed-off-by: Sage Weil <sage@newdream.net> --- fs/btrfs/ctree.h | 1 + fs/btrfs/ioctl.c | 109 +++++++++++++++++++++++++++++++++++++++++++++++++++-- fs/btrfs/super.c | 6 ++- 3 files changed, 110 insertions(+), 6 deletions(-) diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index 5ac2bca..140003e 100644 --- a/fs/btrfs/ctree...

I am testing a Btrfs root file system with Debian (kernel 2.6.32) under KVM. jason@vrtl:~$ touch testfile jason@vrtl:~$ cp --reflink testfile /tmp cp: failed to clone `/tmp/testfile'': Invalid argument This is with GNU Coreutils 8.0 taken from debian Sid. Is this a Coreutils issue, a Btrfs problem or something in my local configuration? All the other issues that I have encountered so

Hi, we are running a ceph cluster with btrfs as it''s base filesystem (kernel 3.0). At the beginning everything worked very well, but after a few days (2-3) things are getting very slow. When I look at the object store servers I see heavy disk-i/o on the btrfs filesystems (disk utilization is between 60% and 100%). I also did some tracing on the Cepp-Object-Store-Daemon, but I''m

I know that this is not the appropriate place :). You know someone can alternative to gluserfs ?:) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20090107/63b68a0d/attachment.html>

...;alex@alex.org.uk> Alex Copot <alex.mihai.c@gmail.com> Alex Deucher <alexander.deucher@amd.com> Alex Deucher <alexdeucher@gmail.com> Alex Dubov <oakad@yahoo.com> Alex Elder <elder@dreamhost.com> Alex Elder <elder@inktank.com> Alex Elder <elder@newdream.net> Alex Ferrando <alferpal@gmail.com> Alex Frid <afrid@nvidia.com> Alex Gershgorin <alexg@meprolight.com> Alex He <alex.he@amd.com> Alex Hung <alex.hung@canonical.com> Alex Iannicelli <alex.iannicelli@emulex.com> Alex Kelly <alex.page.kelly@...