This patch introduce extent buffer cache for every i-node. By this
way, we can save the search time and reduce the lock contention of the root
because we needn't search the item from the root of b+ tree.
Implementation:
- add two pointers of extent buffer into btrfs_inode struct, one for
nodes/l
Move check of write access to mount into upper functions so that we can
use mnt_want_write_file instead, which is faster than mnt_want_write.
Signed-off-by: Liu Bo
---
fs/btrfs/ioctl.c | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/fs/btrfs/ioctl.
mnt_want_write() and mnt_want_write_file() will check sb->s_flags with
MS_RDONLY, and we don't need to do it ourselves.
Signed-off-by: Liu Bo
---
fs/btrfs/ioctl.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index b5e946e..069
$ mkfs.btrfs /dev/sdb7
$ btrfstune -S1 /dev/sdb7
$ mount /dev/sdb7 /mnt/btrfs
mount: block device /dev/sdb7 is write-protected, mounting read-only
$ btrfs dev add /dev/sdb8 /mnt/btrfs/
Now we get a btrfs in which mnt flags has readonly but sb flags does
not. So for those ioctls that only check sb
mnt_want_write_file is faster when file has been opened for write.
Signed-off-by: Liu Bo
---
fs/btrfs/ioctl.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 069cd85..df4c04d 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.
Am Donnerstag, 21. Juni 2012 schrieb Goffredo Baroncelli:
> >
> >
> >> Now we have the possibility to move the kernel near the modules, and
> >> this could lead some interesting possibility: think about different
> >> linux installations, with an own kernel version and an own modules
> >> version;
$ btrfs sub snap /mnt/ /mnt/s1
$ btrfs sub snap /mnt/ /mnt/s2
$ btrfsck disk
then we'll get several "unresolved ref" info, which is not expected.
The cause is that when we make a snapshot, we won't insert root ref/backref
for the snapshot, and btrfsck will report errors.
This is a btrfsck bug, s
>
>You need to understand how a block_rsv works,
>
>both block_rsv and space_info are a kind of _container_:
>
>Introducing metadata reseravtion contexts has two major
>advantages.
>First, it makes metadata reservation more traceable.
>Second, it can reclaim freed space and re-add them
On 06/20/2012 10:47 PM, Goffredo Baroncelli wrote:
>
> This leads to have a separately /boot filesystem. In this case I agree
> with you: make sense that the kernel is near the bootloader files.
>
> But if /boot has to be in a separate filesystem, which is the point to
> support btrfs at all ? Do
Hi Linus,
Please grab my for-linus branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
This is a small pull with btrfs fixes. The biggest of the bunch is
another fix for the new backref walking code.
We're still hammering out one btrfs dio vs buffered reads pr
On 06/21/2012 01:46 PM, Martin Steigerwald wrote:
> Am Donnerstag, 21. Juni 2012 schrieb Goffredo Baroncelli:
>>>
>>>
Now we have the possibility to move the kernel near the modules, and
this could lead some interesting possibility: think about different
linux installations, with an
On 06/21/2012 03:38 PM, H. Peter Anvin wrote:
>> But if /boot has to be in a separate filesystem, which is the point to
>> > support btrfs at all ? Does make sense to support only a subset of btrfs
>> > features ?
>> >
> Yes, and that's another good reason for /boot: btrfs supports that kind
> of
On 06/21/2012 10:05 AM, Goffredo Baroncelli wrote:
> On 06/21/2012 03:38 PM, H. Peter Anvin wrote:
>>> But if /boot has to be in a separate filesystem, which is the point to
support btrfs at all ? Does make sense to support only a subset of btrfs
features ?
>> Yes, and that's another
Those crazy gentoo guys have been complaining about ENOSPC errors on their
portage volumes. This is because doing things like untar tends to create
lots of new files which will soak up all the reservation space in the
delayed inodes. Usually this gets papered over by the fact that we will try
and
+ case FLUSH_DELAYED_ITEMS_NR:
+ case FLUSH_DELAYED_ITEMS:
+ nr = (*state == FLUSH_DELAYED_ITEMS_NR) ? 10 : -1;
This 10 seemed awfully magical so I read a bit more.
It appears to be an attempt to pop back up into reserve_metadata_bytes()
to see if the caller has been
Harald Hoyer has had this as a feature request for ages and I've finally gotten
around to hacking something up. This is probably going to get bikeshedded to
death, bring it on, I'm not married to any of the behaviors in these patches, I
just want to get the ball rolling so we can have something in
This will be used in conjunction with btrfs device ready . This is
needed for initrd's to have a nice and lightweight way to tell if all of the
devices needed for a file system are in the cache currently. This keeps
them from having to do mount+sleep loops waiting for devices to show up.
Thanks,
This command will be used by things like dracut that wish to know very
simply if all of the devices have been added to the kernel cache yet for the
device to be fully mounted. This keeps initrd's from constantly having to
try to mount the file system until it succeeds every time a device is added
On 06/21/2012 03:33 PM, Zach Brown wrote:
+ case FLUSH_DELAYED_ITEMS_NR:
+ case FLUSH_DELAYED_ITEMS:
+ nr = (*state == FLUSH_DELAYED_ITEMS_NR) ? 10 : -1;
This 10 seemed awfully magical so I read a bit more.
It appears to be an attempt to pop back up into reserve_met
Ugh sorry I just dug this patch out from last week and forgot I had just
picked an arbitrary number to make sure it was working. You are correct,
what I _meant_ to do (and will do after I respond) was calculate how
much we wanted to flush and then divide that by how much the delayed
inodes reser
__btrfs_std_error() neglects to call va_end() when doing early return
after testing "if (errno == -EROFS && (sb->s_flags & MS_RDONLY))" and
btrfs_printk() doesn't call va_end() at all.
This patch makes sure that va_end() is always properly called.
Signed-off-by: Jesper Juhl
---
fs/btrfs/super.c
(2012/06/21 20:48), Liu Bo wrote:
> $ mkfs.btrfs /dev/sdb7
> $ btrfstune -S1 /dev/sdb7
> $ mount /dev/sdb7 /mnt/btrfs
> mount: block device /dev/sdb7 is write-protected, mounting read-only
> $ btrfs dev add /dev/sdb8 /mnt/btrfs/
>
> Now we get a btrfs in which mnt flags has readonly but sb flags d
Hello Btrfs devs,
The patch 5d4f98a28c7d: "Btrfs: Mixed back reference (FORWARD
ROLLING FORMAT CHANGE)" from Jun 10, 2009, leads to the following
warning:
fs/btrfs/relocation.c:1270 __update_reloc_root()
error: potential NULL dereference 'node'.
fs/btrfs/relocation.c
1255 static int
23 matches
Mail list logo
