On Thu, Apr 12, 2012 at 2:32 PM, David Sterba wrote:
> On Thu, Apr 12, 2012 at 02:09:08PM +0300, Kasatkin, Dmitry wrote:
>> Where is it? Can you please point out?
>
> http://permalink.gmane.org/gmane.comp.file-systems.btrfs/16662
>
> the relevant part:
>
> -- a/fs/btrfs/super.c
> +++ b/fs/btrfs/su
Daniel Pocock posted on Wed, 09 May 2012 22:01:49 + as excerpted:
> There is various information about
> - enterprise-class drives (either SAS or just enterprise SATA)
> - the SCSI/SAS protocols themselves vs SATA having more advanced
> features (e.g. for dealing with error conditions)
> than
On Mon, May 7, 2012 at 5:44 PM, David Sterba wrote:
> the time of temporary wiki hosted at btrfs.ipv5.de is over, the content has
> been migrated back to official site at
>
> http://btrfs.wiki.kernel.org
>
> (ipv5.de wiki is set to redirect there).
Excellent, great job! Much appreciated. How
On Fri, Apr 27, 2012 at 01:02:08PM +0200, Christian Brunner wrote:
> Am 24. April 2012 18:26 schrieb Sage Weil :
> > On Tue, 24 Apr 2012, Josef Bacik wrote:
> >> On Fri, Apr 20, 2012 at 05:09:34PM +0200, Christian Brunner wrote:
> >> > After running ceph on XFS for some time, I decided to try btrfs
On Thursday 10 of May 2012 21:15:30 Hugo Mills wrote:
> On Thu, May 10, 2012 at 09:43:58PM +0200, Hubert Kario wrote:
> > On Thursday 10 of May 2012 12:40:49 Martin Steigerwald wrote:
> > > Am Mittwoch, 9. Mai 2012 schrieb Kaspar Schleiser:
> > > > Hi,
> > > >
> > > > On 05/08/2012 10:56 PM, Roman
On Thu, May 10, 2012 at 09:43:58PM +0200, Hubert Kario wrote:
> On Thursday 10 of May 2012 12:40:49 Martin Steigerwald wrote:
> > Am Mittwoch, 9. Mai 2012 schrieb Kaspar Schleiser:
> > > Hi,
> > >
> > > On 05/08/2012 10:56 PM, Roman Mamedov wrote:
> > > > Regarding btrfs, AFAIK even "btrfs -d sing
On Wednesday 09 of May 2012 22:01:49 Daniel Pocock wrote:
> There is various information about
> - enterprise-class drives (either SAS or just enterprise SATA)
> - the SCSI/SAS protocols themselves vs SATA
> having more advanced features (e.g. for dealing with error conditions)
> than the average b
On Thursday 10 of May 2012 12:40:49 Martin Steigerwald wrote:
> Am Mittwoch, 9. Mai 2012 schrieb Kaspar Schleiser:
> > Hi,
> >
> > On 05/08/2012 10:56 PM, Roman Mamedov wrote:
> > > Regarding btrfs, AFAIK even "btrfs -d single" suggested above works
> > > not "per file", but per allocation extent,
On Fri, Apr 27, 2012 at 01:02:08PM +0200, Christian Brunner wrote:
> Am 24. April 2012 18:26 schrieb Sage Weil :
> > On Tue, 24 Apr 2012, Josef Bacik wrote:
> >> On Fri, Apr 20, 2012 at 05:09:34PM +0200, Christian Brunner wrote:
> >> > After running ceph on XFS for some time, I decided to try btrfs
Am Montag, 7. Mai 2012 schrieb Martin Steigerwald:
> Am Sonntag, 6. Mai 2012 schrieb Ilya Dryomov:
> > On Sun, May 06, 2012 at 01:19:38PM +0200, Martin Steigerwald wrote:
> > > Am Freitag, 4. Mai 2012 schrieb Martin Steigerwald:
> > > > Am Freitag, 4. Mai 2012 schrieb Martin Steigerwald:
[…]
> > >
Hi,
I've got three servers here with corrupted btrfs filesystems. These servers
were/are part of a ceph cluster that was physically moved a few months ago.
The servers may have been incorrectly powered off without a proper shutdown
during the move, but that's hard to find out now. (It wasn't me
On Thu, May 10, 2012 at 10:23:28AM +0200, Jan Schmidt wrote:
> On Wed, May 09, 2012 at 19:02 (+0200), Chris Mason wrote:
> +
> +while (1) {
> +ret = btrfs_find_one_extref(fs_root, inum, offset,
> path, &iref2,
> +
Hallo, Martin,
Du meintest am 10.05.12:
[...]
>> Maybe we should evaluate the possiblility of such a "one file gets
>> on one disk" feature.
>>
>> Helmut Hullen has the use case: Many disks, totally non-critical but
>> nice-to-have data. If one disk dies, some *files* should lost, not
>> some *r
Am Mittwoch, 9. Mai 2012 schrieb Kaspar Schleiser:
> Hi,
>
> On 05/08/2012 10:56 PM, Roman Mamedov wrote:
> > Regarding btrfs, AFAIK even "btrfs -d single" suggested above works
> > not "per file", but per allocation extent, so in case of one disk
> > failure you will lose random *parts* (extents)
Fully utilize our extent state's new helper functions to use
fastpath as much as possible.
Signed-off-by: Liu Bo
---
fs/btrfs/extent_io.c | 44 ++--
1 files changed, 18 insertions(+), 26 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_i
Reproduce:
$ mkfs.btrfs /dev/sdb7
$ mount /dev/sdb7 /mnt/btrfs -o ro
$ btrfs dev add /dev/sdb8 /mnt/btrfs
ERROR: error adding the device '/dev/sdb8' - Invalid argument
Since we mount with readonly options, and /dev/sdb7 is not a seeding one,
a readonly notification is preferred.
Signed-off-by: Li
On Wed, May 09, 2012 at 19:02 (+0200), Chris Mason wrote:
+
+ while (1) {
+ ret = btrfs_find_one_extref(fs_root, inum, offset, path, &iref2,
+ &offset);
+ if (ret < 0)
+ break;
+ if
17 matches
Mail list logo
