On Fri, Jun 06, 2014 at 02:32:39PM +0800, Gui Hecheng wrote:
> But for now, there are btrfs *users* complaining that they cannot find
> any help by refering to the mount manpage when they want to mount their
> btrfs. Actually, not every btrfs user have the mood to check the
> Documentation/filesyst
On Fri, Jun 06, 2014 at 11:44:28AM +0200, Karel Zak wrote:
> I personally have no problem to maintain information about arbitrary
> FS in mount.8, the problem are updates. Unfortunately, kernel FS developers
> don't care about the man page at all and it's very often not up to date.
Hmm.. anoth
On Fri, 2014-06-06 at 11:44 +0200, Karel Zak wrote:
> On Fri, Jun 06, 2014 at 02:32:39PM +0800, Gui Hecheng wrote:
> > But for now, there are btrfs *users* complaining that they cannot find
> > any help by refering to the mount manpage when they want to mount their
> > btrfs. Actually, not every bt
On Fri, 2014-06-06 at 12:03 +0200, Karel Zak wrote:
> On Fri, Jun 06, 2014 at 11:44:28AM +0200, Karel Zak wrote:
> > I personally have no problem to maintain information about arbitrary
> > FS in mount.8, the problem are updates. Unfortunately, kernel FS developers
> > don't care about the man p
On Thu, Jun 05, 2014 at 10:05:19AM +0800, Gui Hecheng wrote:
> Based on Documentation/filesystems/btrfs.txt
>
> Signed-off-by: Gui Hecheng
> ---
> sys-utils/mount.8 | 186
> ++
> 1 file changed, 186 insertions(+)
Applied, thanks.
Karel
On Fri, Jun 06, 2014 at 05:05:51AM +0100, Filipe David Borba Manana wrote:
> When cloning into a file, we were correctly replacing the extent
> items in the target range and removing the extent maps. However
> we weren't replacing the extent maps with new ones that point to
> the new extents - as a
On Thu, Jun 05, 2014 at 04:15:51PM -0400, Josef Bacik wrote:
> We have been iterating all references for each extent we have in a file when
> we
> do fiemap to see if it is shared. This is fine when you have a few clones or
> a
> few snapshots, but when you have 5k snapshots suddenly fiemap just
On Fri, Jun 6, 2014 at 7:25 AM, Liu Bo wrote:
> Several reports about leaf corruption has been floating on the list, one of
> them
> points to __btrfs_drop_extents(), and we find that the leaf becomes corrupted
> after __btrfs_drop_extents(), it's really a rare case but it does exist.
>
> The pro
On Fri, 06 Jun 2014 14:25:58 +0800, Liu Bo wrote:
> Several reports about leaf corruption has been floating on the list, one
> of them points to __btrfs_drop_extents(), and we find that the leaf
> becomes corrupted after __btrfs_drop_extents(), it's really a rare case
> but it does exist.
Out of
When cloning into a file, we were correctly replacing the extent
items in the target range and removing the extent maps. However
we weren't replacing the extent maps with new ones that point to
the new extents - as a consequence, an incremental fsync (when the
inode doesn't have the full sync flag)
Hello,
Not sure if this has been reported somewhere closer to Btrfs development, and
not just in Debian... Anyways, just now I (also) hit this bug when upgrading my
kernel from 3.12.21 to 3.14.5 on one machine (but not on a number of others):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=74
When cloning into a file, we were correctly replacing the extent
items in the target range and removing the extent maps. However
we weren't replacing the extent maps with new ones that point to
the new extents - as a consequence, an incremental fsync (when the
inode doesn't have the full sync flag)
On Fri, Jun 6, 2014 at 3:40 PM, Roman Mamedov wrote:
> Hello,
>
> Not sure if this has been reported somewhere closer to Btrfs development, and
> not just in Debian... Anyways, just now I (also) hit this bug when upgrading
> my
> kernel from 3.12.21 to 3.14.5 on one machine (but not on a number o
On 6/6/14, 5:03 AM, Karel Zak wrote:
> On Fri, Jun 06, 2014 at 11:44:28AM +0200, Karel Zak wrote:
>> I personally have no problem to maintain information about arbitrary
>> FS in mount.8, the problem are updates. Unfortunately, kernel FS developers
>> don't care about the man page at all and it'
On 6 June 2014 16:41, Filipe David Manana wrote:
> On Fri, Jun 6, 2014 at 3:40 PM, Roman Mamedov wrote:
>> Hello,
>>
>> Not sure if this has been reported somewhere closer to Btrfs development, and
>> not just in Debian... Anyways, just now I (also) hit this bug when upgrading
>> my
>> kernel fr
On Fri, 6 Jun 2014 19:31:37 +0100
WorMzy Tykashi wrote:
> My solution was to write a patch for mkinitcpio (Arch initrd creation
> tool) [1] so that it explicitly adds the crc32c module to the initrd
> if btrfs is needed. I imagine it wouldn't be difficult to add the same
> logic to debian's initr
On Thu, Jun 5, 2014 at 2:53 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Timofey Titovets posted on Thu, 05 Jun 2014 19:13:08 +0300 as excerpted:
>
>> 2014-06-05 18:52 GMT+03:00 Igor M :
>>> One more question. Is there any other way to find out file
>>> fragmentation ?
>>> I just copied 35Gb file on
Mitch Harder posted on Fri, 06 Jun 2014 14:06:53 -0500 as excerpted:
> Every time you update your database, btrfs is going to update whichever
> 128 KiB blocks need to be modified.
>
> Even for a tiny modification, the new compressed block may be slightly
> more or slightly less than 128 KiB.
FW
On 6 June 2014 19:53, Roman Mamedov wrote:
> On Fri, 6 Jun 2014 19:31:37 +0100
> WorMzy Tykashi wrote:
>
>> My solution was to write a patch for mkinitcpio (Arch initrd creation
>> tool) [1] so that it explicitly adds the crc32c module to the initrd
>> if btrfs is needed. I imagine it wouldn't be
Hi Linus,
I had this in my 3.16 merge window queue, but it is small and obvious
enough for 3.15. I cherry-picked and retested against current rc8.
Please pull from my for-linus branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
Filipe Manana (1) commits (+5/
On Tue, 2014-06-03 at 19:03 +0200, Goffredo Baroncelli wrote:
> There is (was ?) a project to address that: richacl
> http://www.bestbits.at/richacl/.
> This is not a btrfs project, but a linux kernel project because from a
> filesystem POV the implementation requires to store some information
On Fri, 6 Jun 2014 14:06:53 Mitch Harder wrote:
> Every time you update your database, btrfs is going to update
> whichever 128 KiB blocks need to be modified.
>
> Even for a tiny modification, the new compressed block may be slightly
> more or slightly less than 128 KiB.
>
> If you have a 1-2 GB
22 matches
Mail list logo
