Hello,
I have a question regarding btrfs filesystem dfoutput.
# 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
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 directory, we
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 t-i...@jp.fujitsu.com
---
fs/btrfs/ctree.c|6 +-
fs/btrfs/tree-log.c | 16 +---
2 files
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
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 trivial.
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 list.bt...@jan-o-sch.net wrote:
On Mon, May 28, 2012 at 20:45 (+0200), Alex Lyakas wrote:
I have
On Tue, May 29, 2012 at 5:18 AM, David Sterba d...@jikos.cz 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
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
On Tue, May 29, 2012 at 10:14 AM, Boaz Harrosh bharr...@panasas.com 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
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
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 +
@@
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
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
it,
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
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
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
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
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
On Tue, May 29, 2012 at 5:14 PM, Felix Blanke felixbla...@gmail.com 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.
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
On Tue, May 29, 2012 at 5:24 PM, Maxim Mikheev mik...@gmail.com 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
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.
25 matches
Mail list logo
