On Tue, 18 Nov 2014 09:29:54 +0200
Brendan Hide wrote:
> Hey, guys
>
> See further below extracted output from a daily scrub showing csum
> errors on sdb, part of a raid1 btrfs. Looking back, it has been getting
> errors like this for a few days now.
>
> The disk is patently unreliable but sm
Hey, guys
See further below extracted output from a daily scrub showing csum
errors on sdb, part of a raid1 btrfs. Looking back, it has been getting
errors like this for a few days now.
The disk is patently unreliable but smartctl's output implies there are
no issues. Is this somehow standar
On Fri, Nov 14, 2014 at 04:16:30PM -0500, Josef Bacik wrote:
> We use the modified list to keep track of which extents have been modified so
> we
> know which ones are candidates for logging at fsync() time. Newly modified
> extents are added to the list at modification time, around the same time
On Nov 16, 2014, at 11:59 PM, Brendan Hide wrote:
> cc'd bug-g...@gnu.org for FYI
>
> On 2014/11/17 03:42, Duncan wrote:
>> MegaBrutal posted on Sun, 16 Nov 2014 22:35:26 +0100 as excerpted:
>>
>>> Hello guys,
>>>
>>> I think you'll like this...
>>> https://bugs.launchpad.net/ubuntu/+source/g
On Nov 17, 2014, at 12:45 PM, MegaBrutal wrote:
> 2014-11-17 20:04 GMT+01:00 Goffredo Baroncelli :
>>
>> Regarding b)
>> I am bit confused: if I understood correctly, the root filesystem was
>> picked from a LVM-snapshot, so grub-probe *correctly* reported that
>> the root device is the snapsho
On Nov 17, 2014, at 3:55 PM, Fennec Fox wrote:
> well i am an arch linux user and machine owner using a failing drive
> its still relyable enough for me but btrfs seems not to mark bad
> blocks as unusable and continues to try to write to them.
It’s supposed to do try to write to them. If ther
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/17/2014 05:55 PM, Fennec Fox wrote:
> well i am an arch linux user and machine owner using a failing
> drive its still relyable enough for me but btrfs seems not to mark
> bad blocks as unusable and continues to try to write to them.
> /bbs.ar
well i am an arch linux user and machine owner using a failing drive
its still relyable enough for me but btrfs seems not to mark bad
blocks as unusable and continues to try to write to them.
/bbs.archlinux.org/viewtopic.php?pid=1476540#p1476540 this forum post
has a few more details regarding
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/11/2014 3:29 AM, Goffredo Baroncelli wrote:
> On 10/10/2014 12:53 PM, Bob Marley wrote:
>>>
>>> If true, maybe the closest indication we'd get of btrfs
>>> stablity is the default enabling of autorecovery.
>>
>> No way! I wouldn't want a defaul
On 2014-11-17 20:45, MegaBrutal wrote:
> * I know I shouldn't make an LVM-snapshot of a mounted file system,
> but this is not the point.
This should be supported for the filesystem which support the freezing
See
http://stackoverflow.com/questions/1940093/lvm-snapshot-of-mounted-filesystem
--
2014-11-17 20:04 GMT+01:00 Goffredo Baroncelli :
>
> Regarding b)
> I am bit confused: if I understood correctly, the root filesystem was
> picked from a LVM-snapshot, so grub-probe *correctly* reported that
> the root device is the snapshot.
This is not what happens. The system doesn't even get
On 2014-11-17 07:59, Brendan Hide wrote:
>
> That leaves two aspects of this issue which I view as two separate bugs:
> a) Btrfs cannot gracefully handle separate filesystems that have the same
> UUID. At all.
> b) Grub appears to pick the wrong filesystem when presented with two
> filesystems w
With the new iov_iter infrastructure that supprots direct I/O to kernel
pages please get rid of the ->readpage hack first. I'm still utterly
disapoined that this crap ever got merged.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@v
This is the second independent patch of a larger
project to cleanup btrfs's internal usage of
btrfs_root. Many functions take btrfs_root
only to grab the fs_info struct.
By requiring a root these functions cause
programmer overhead. That these functions can
accept any valid root is not obvious unt
On Mon, Nov 17, 2014 at 11:59:48AM +0100, Konstantin wrote:
> Josef Bacik wrote on 14.11.2014 at 23:00:
> > On 11/14/2014 04:51 PM, Hugo Mills wrote:
[snip]
> >> Problem 2: Unexplained zeroes
> >>
> >> Failure to mount. Transid failure, "expected xyz, have 0". Chris
> >> looked at an early one
On Fri, Nov 14, 2014 at 05:00:26PM -0500, Josef Bacik wrote:
> On 11/14/2014 04:51 PM, Hugo Mills wrote:
> >Chris, Josef, anyone else who's interested,
> >
> >On IRC, I've been seeing reports of two persistent unsolved
> >problems. Neither is showing up very often, but both have turned up
>
Josef Bacik wrote on 14.11.2014 at 23:00:
> On 11/14/2014 04:51 PM, Hugo Mills wrote:
>> Chris, Josef, anyone else who's interested,
>>
>> On IRC, I've been seeing reports of two persistent unsolved
>> problems. Neither is showing up very often, but both have turned up
>> often enough to in
This is probably the nastiest part of the patch series. Swapcache pages don't
use the ->mapping and ->index fields of the struct page. Instead, the
swp_entry_t in ->private points to the desired swap area and offset within it.
To support operating on swapcache pages in BTRFS, we need to get the map
This patch series, based on 3.18-rc5, implements support for swap files on
BTRFS.
The standard swap file implementation uses the filesystem's implementation of
bmap() to get a list of physical blocks on disk, which the swap file code then
does I/O on directly without going through the filesystem.
swap_activate will check for a compressed or copy-on-write file; we shouldn't
allow it to become either once it has already been activated.
Signed-off-by: Omar Sandoval
---
fs/btrfs/ioctl.c | 50 +++---
1 file changed, 31 insertions(+), 19 deletions(-)
Signed-off-by: Omar Sandoval
---
fs/btrfs/extent_io.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 54b2d00..b8dc256 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2904,13 +2904,14 @@ static int __do_re
Swapcache pages use ->private to store the swp_entry_t; overwriting it is sure
to cause insanity.
Signed-off-by: Omar Sandoval
---
fs/btrfs/extent_io.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 9b67b37..54b2d00 10064
As pages in the swapcache get shuffled around and repurposed for different
pages in the swap file, the EXTENT_UPTODATE flag doesn't apply. This leads to
some really weird symptoms in userspace where pages in a process's address
space appear to get mixed up.
Signed-off-by: Omar Sandoval
---
fs/bt
Implement the swap file a_ops on btrfs. Activation simply checks for a usable
swap file: it must be fully allocated (no holes), support direct I/O (so no
compressed or inline extents) and should be nocow (I'm not sure about that last
one).
Signed-off-by: Omar Sandoval
---
fs/btrfs/inode.c | 71 +
On 2014/11/17 09:35, Daniel Dressler top-posted:
If a UUID is not unique enough how will adding a second UUID or
"unique drive identifier" help?
A UUID is *supposed* to be unique by design. Isolated, the design is
adequate.
But the bigger picture clearly shows the design is naive. And broken.
2014-11-17 7:59 GMT+01:00 Brendan Hide :
>
> Grub is already a little smart here - it avoids snapshots. But in this case
> it is relying on the UUID and only finding it in the snapshot. So possibly
> this is a bug in grub affecting the bug reporter specifically - but perhaps
> the bug is in btrf
Dear Sir
Did your website get hit by Google Penguin update on October 17th 2014? What
basically is Google Penguin Update? It is actually a code name for Google
algorithm which aims at decreasing your websites search engine rankings that
violate Googles guidelines by using black hat SEO techniq
27 matches
Mail list logo
