2014-11-17 7:59 GMT+01:00 Brendan Hide bren...@swiftspirit.co.za:
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
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.
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 osan...@osandov.com
---
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
Signed-off-by: Omar Sandoval osan...@osandov.com
---
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
Swapcache pages use -private to store the swp_entry_t; overwriting it is sure
to cause insanity.
Signed-off-by: Omar Sandoval osan...@osandov.com
---
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
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 osan...@osandov.com
---
fs/btrfs/ioctl.c | 50 +++---
1 file changed, 31
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
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 indicate
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
often
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 of these (for
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
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
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 with
2014-11-17 20:04 GMT+01:00 Goffredo Baroncelli kreij...@inwind.it:
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
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
--
-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 default like that.
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: 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.
On Nov 17, 2014, at 3:55 PM, Fennec Fox fennect...@gmail.com 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
On Nov 17, 2014, at 12:45 PM, MegaBrutal megabru...@gmail.com wrote:
2014-11-17 20:04 GMT+01:00 Goffredo Baroncelli kreij...@inwind.it:
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
On Nov 16, 2014, at 11:59 PM, Brendan Hide bren...@swiftspirit.co.za 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...
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
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
On Tue, 18 Nov 2014 09:29:54 +0200
Brendan Hide bren...@swiftspirit.co.za 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
26 matches
Mail list logo
