[PATCH] Deny sys_link across subvolumes.

2009-11-11 Thread TARUISI Hiroaki
From: Christian Parpart I rebased Christian Parpart's patch to deny hard link across subvolumes. Original patch modifies also btrfs_rename, but I excluded it because we can move across subvolumes now and it make no problem. - Hard link across subvolumes should not allowed in Btr

Re: [RFC] big fat transaction ioctl

2009-11-11 Thread Andrey Kuzmin
On Wed, Nov 11, 2009 at 8:19 PM, Sage Weil wrote: > On Wed, 11 Nov 2009, Chris Mason wrote: > >> On Tue, Nov 10, 2009 at 02:13:10PM -0800, Sage Weil wrote: >> > On Tue, 10 Nov 2009, Andrey Kuzmin wrote: >> > >> > > On Tue, Nov 10, 2009 at 11:12 PM, Sage Weil wrote: >> > > > Hi all, >> > > > >> >

btrfsck: checksum verify failed

2009-11-11 Thread Alexander Beregalov
# for i in `seq 1 20`; do btrfsck /dev/sde|grep "checksum verify failed";echo; done checksum verify failed on 31945617408 wanted 6607632D found 9CC3ED0 checksum verify failed on 31945617408 wanted 6607632D found AFBBF41 checksum verify failed on 31945617408 wanted 6607632D found A4F0ED0 checksum v

Re: BUG? a possible race due to the absence of memory barrier

2009-11-11 Thread 홍신 shin hong
Thank you for the review. I did not notice that lock_chunks() is a locking function. I am using my own static analysis for finding bugs. As I register lock_chunks() as a locking functions, the bug alarm is disappeared. On Thu, Nov 12, 2009 at 1:06 AM, Chris Mason wrote: > On Thu, Nov 12, 2009 a

Re: [RFC] big fat transaction ioctl

2009-11-11 Thread Sage Weil
On Wed, 11 Nov 2009, Zach Brown wrote: > > I like this much more than providing a journal start/stop to userland. > > If we can get Christoph to ack the exports we can work on the interface > > in general. > > I'll note, briefly, that it seems dangerous to call right into the sys_ > functions inst

Re: [patch] avoid null deref in unpin_extent_cache()

2009-11-11 Thread Chris Mason
On Tue, Nov 10, 2009 at 11:01:43AM +0200, Dan Carpenter wrote: > I re-orderred the checks to avoid dereferencing "em" if it was null. Thanks, I've put this into the master branch of the btrfs unstable tree. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the bo

[GIT PULL] Btrfs updates for 2.6.32-rc

2009-11-11 Thread Chris Mason
Hello everyone, The master branch of the btrfs-unstable repo has an assortment of fixes and speedups. git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git master These are mostly minor fixes, but there is an important fix for using btrfs and ceph together. Josef has a block gr

Re: [RFC] big fat transaction ioctl

2009-11-11 Thread Zach Brown
> I like this much more than providing a journal start/stop to userland. > If we can get Christoph to ack the exports we can work on the interface > in general. I'll note, briefly, that it seems dangerous to call right into the sys_ functions instead of going through the architecture's syscall nu

Re: [RFC] big fat transaction ioctl

2009-11-11 Thread Sage Weil
On Wed, 11 Nov 2009, Chris Mason wrote: > On Tue, Nov 10, 2009 at 02:13:10PM -0800, Sage Weil wrote: > > On Tue, 10 Nov 2009, Andrey Kuzmin wrote: > > > > > On Tue, Nov 10, 2009 at 11:12 PM, Sage Weil wrote: > > > > Hi all, > > > > > > > > This is an alternative approach to atomic user transacti

Re: BUG? a possible race due to the absence of memory barrier

2009-11-11 Thread Chris Mason
On Thu, Nov 12, 2009 at 12:07:05AM +0900, 홍신 shin hong wrote: > Hello. I am reporting possible data race > due to the the absence of memory barriers. > > I reported a similar issue. Although the previous one turns out to be safe, > please examine this issue and let me know your opinion. > > In bt

Re: [RFC] big fat transaction ioctl

2009-11-11 Thread Chris Mason
On Wed, Nov 11, 2009 at 06:41:06PM +0300, Andrey Kuzmin wrote: > >> I hadn't looked into this before, but I think the snapshots could be used > >> to achieve both atomicity and rollback.  If userspace uses an rw mutex to > >> quiesce writes, it can make sure all transactions complete before creatin

Re: [RFC] big fat transaction ioctl

2009-11-11 Thread Andrey Kuzmin
On Wed, Nov 11, 2009 at 6:03 PM, Chris Mason wrote: > On Tue, Nov 10, 2009 at 02:13:10PM -0800, Sage Weil wrote: >> On Tue, 10 Nov 2009, Andrey Kuzmin wrote: >> >> > On Tue, Nov 10, 2009 at 11:12 PM, Sage Weil wrote: >> > > Hi all, >> > > >> > > This is an alternative approach to atomic user tran

BUG? a possible race due to the absence of memory barrier

2009-11-11 Thread 홍신 shin hong
Hello. I am reporting possible data race due to the the absence of memory barriers. I reported a similar issue. Although the previous one turns out to be safe, please examine this issue and let me know your opinion. In btrfs_init_new_device(), a btrfs_device object is allocated and initialized an

Re: [RFC] big fat transaction ioctl

2009-11-11 Thread Chris Mason
On Tue, Nov 10, 2009 at 02:13:10PM -0800, Sage Weil wrote: > On Tue, 10 Nov 2009, Andrey Kuzmin wrote: > > > On Tue, Nov 10, 2009 at 11:12 PM, Sage Weil wrote: > > > Hi all, > > > > > > This is an alternative approach to atomic user transactions for btrfs. > > > The old start/end ioctls suffer fr

Re: [RFC] big fat transaction ioctl

2009-11-11 Thread Chris Mason
On Tue, Nov 10, 2009 at 12:12:14PM -0800, Sage Weil wrote: > Hi all, > > This is an alternative approach to atomic user transactions for btrfs. > The old start/end ioctls suffer from some basic limitations, namely > > - We can't properly reserve space ahead of time to avoid ENOSPC part > way