Hello,
I have a question regarding "btrfs filesystem df"output.
# btrfs fi df /mnt/test
Data: total=3.01GB, used=512.19MB
System, DUP: total=8.00MB, used=4.00KB
System: total=4.00MB, used=0.00 <= What this
means? For what is used? I've never seen this incremented
Metada
On 05/25/2012 06:35 PM, Alexander Block wrote:
> Hello,
>
> (this is a resend with proper CC for linux-fsdevel and linux-kernel)
>
> I would like to start a discussion on atime in Btrfs (and other
> filesystems with snapshot support).
>
> As atime is updated on every access of a file or directo
btrfs_read_buffer() has the possibility of returning the error.
Therefore, I add the code in which the return value of btrfs_read_buffer()
is checked.
Signed-off-by: Tsutomu Itoh
---
fs/btrfs/ctree.c|6 +-
fs/btrfs/tree-log.c | 16 +---
2 files changed, 18 insertions(+)
On Mon, May 28, 2012 at 20:45 (+0200), Alex Lyakas wrote:
> I have re-looked at btrfs_search_slot, and don't see how it would end
> up in leaf B. The bin_search() function will clearly return the slot
> *after* the slot of N that has key==5 (which is the parent slot of A).
> So then the following c
On Tue, May 29, 2012 at 08:40:10AM +0800, Li Zefan wrote:
> > Is there any way to mark existing snapshots as read-only? Making new
> > ones read-only is easy enough, but what about existing ones?
>
> We have code in the kernel side, so what we need to do is to update
> btrfs-progs,
> which is tri
Thank you Jan, Hugo & Lio,
for taking time answering my questions.
Alex.
P.S.: I have dug in some more, so probably more questions will arrive:)
On Tue, May 29, 2012 at 12:13 PM, Jan Schmidt wrote:
> On Mon, May 28, 2012 at 20:45 (+0200), Alex Lyakas wrote:
>> I have re-looked at btrfs_search_s
On Tue, May 29, 2012 at 5:18 AM, David Sterba wrote:
> On Tue, May 29, 2012 at 08:40:10AM +0800, Li Zefan wrote:
>> > Is there any way to mark existing snapshots as read-only? Making new
>> > ones read-only is easy enough, but what about existing ones?
>>
>> We have code in the kernel side, so wha
2012-05-28 12:37:00 -0600, Bruce Guenter:
>
> Is there any way to mark existing snapshots as read-only? Making new
> ones read-only is easy enough, but what about existing ones?
[...]
you can always do
btrfs sub snap -r vol vol-ro
btrfs sub del vol
mv vol-ro vol
--
Stephane
--
To unsubscribe
Thanks for noting this one. That is one very surprising and unexpected
limit!... And a killer for some not completely rare applications...
On 26/05/12 19:22, Sami Liedes wrote:
> Hi!
>
> I see that Linux 3.4 supports bigger metadata blocks for btrfs.
>
> Will using them allow a bigger number of
On Tue, May 29, 2012 at 02:09:03PM +0100, Martin wrote:
> Thanks for noting this one. That is one very surprising and unexpected
> limit!... And a killer for some not completely rare applications...
There have been substantially-complete patches posted to this list
which fix the problem (see "e
On Tue, May 29, 2012 at 10:14 AM, Boaz Harrosh wrote:
>
> Sounds like a real problem. I would suggest a few remedies.
> 1. Make a filesystem persistent parameter that says noatime/relatime/atime
> So the default if not specified on mount is taken as a property of
> the FS (mkfs can set it)
Tha
This is a several bugs fixed version since my first patch commit, and added
patch of btrfs-prog
Introduction and brief speculate of values and penalties:
When a tree block need to be created, we offer, say, 2 or 3 blocks for
it,
then pick one from the continuous blocks. If this tree b
signed-off-by WeiFeng Liu
523f28f9b3d9c710cacc31dbba644efb1678cf62
---
diff -uprN btrfs-progs-120328-a/ctree.c btrfs-progs-120328-b/ctree.c
--- btrfs-progs-120328-a/ctree.c2012-04-16 08:47:08.0 +
+++ btrfs-progs-120328-b/ctree.c2012-05-28 23:29:15.0 +
@@ -33
This is a several bugs fixed version since my first patch commit, and added
patch of btrfs-prog
Introduction and brief speculate of values and penalties:
When a tree block need to be created, we offer, say, 2 or 3 blocks for
it,
then pick one from the continuous blocks. If this tree bl
Hi Liu,
On 05/29/2012 06:24 PM, WeiFeng Liu wrote:
> This is a several bugs fixed version since my first patch commit, and added
> patch of btrfs-prog
>
>
> Introduction and brief speculate of values and penalties:
>
> When a tree block need to be created, we offer, say, 2 or 3 blocks for
So dpkg fsync()'s the file and the directory containing the file whenever it
writes to a file which is really slow in btrfs. This is partly because
fsync()'ing a directory _always_ committed the transaction instead of just
going to the tree log. This is because drop_objectid_items() would return
We have this check down in the actual logging code, but this is after we
start a transaction and all that good stuff. So move the helper
inode_in_log() out so we can call it in fsync() and avoid starting a
transaction altogether and just exit if we've already fsync()'ed this file
recently. You wo
Hi Everyone,
I recently decided to use btrfs. It works perfectly for a week even
under heavy load. Yesterday I destroyed backups as cannot afford to have
~10TB in backups. I decided to switch on Btrfs because it was announced
that it stable already
I need to recover ~5TB data, this data is imp
After command:
sudo /usr/local/bin/btrfs device scan
i got new lines in dmesg:
11329.598535] device fsid c9776e19-37eb-4f9c-bd6b-04e8dde97682 devid 2
transid 9096 /dev/sdb
[11329.599885] device fsid c9776e19-37eb-4f9c-bd6b-04e8dde97682 devid 3
transid 9095 /dev/sdd
[11329.600840] device fsid
I can't help much at the moment, but the following will help sort things out:
Can you provide as much detail as possible about how things were
configured at the time of the failure? Raid levels used, kernel
versions at the time of the failure, how the disks are connected,
general description of t
On 5/30/12 12:14 AM, Maxim Mikheev wrote:
Hi Everyone,
I recently decided to use btrfs. It works perfectly for a week even
under heavy load. Yesterday I destroyed backups as cannot afford to have
~10TB in backups. I decided to switch on Btrfs because it was announced
that it stable already
I n
On Tue, May 29, 2012 at 5:14 PM, Felix Blanke wrote:
>
>
> On 5/30/12 12:14 AM, Maxim Mikheev wrote:
>>
>> Hi Everyone,
>>
>> I recently decided to use btrfs. It works perfectly for a week even
>> under heavy load. Yesterday I destroyed backups as cannot afford to have
>> ~10TB in backups. I decid
Thank you for your answer.
The system kernel was and now:
Linux s0 3.4.0-030400-generic #201205210521 SMP Mon May 21 09:22:02 UTC
2012 x86_64 x86_64 x86_64 GNU/Linux
the raid was created by:
mkfs.btrfs /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf
Disk are connected through RocketRaid 2670.
I forgot to add.
Btrfs-tools was build from:
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git
On 05/29/2012 07:24 PM, Maxim Mikheev wrote:
Thank you for your answer.
The system kernel was and now:
Linux s0 3.4.0-030400-generic #201205210521 SMP Mon May 21 09:22
On Tue, May 29, 2012 at 5:24 PM, Maxim Mikheev wrote:
> Thank you for your answer.
>
>
> The system kernel was and now:
>
> Linux s0 3.4.0-030400-generic #201205210521 SMP Mon May 21 09:22:02 UTC 2012
> x86_64 x86_64 x86_64 GNU/Linux
>
> the raid was created by:
> mkfs.btrfs /dev/sdb /dev/sdc /dev
On 05/30/2012 04:57 AM, Josef Bacik wrote:
> So dpkg fsync()'s the file and the directory containing the file whenever it
> writes to a file which is really slow in btrfs. This is partly because
> fsync()'ing a directory _always_ committed the transaction instead of just
> going to the tree log.
26 matches
Mail list logo
