Howdy,
How does one get the exact size (in blocks preferably, but bytes okay)
of the filesystem inside a partition? I know how to get the partition
size, but that's not useful when shrinking a partition...
So, for example, you successfully do
btrfs filesystem resize -32G /dev/sdz2
now
So here's a thing...
If you've got a BTRFS root file system and you mount go to resize a
removable media and you make a typo you can easily resize your root
instead of a target.
mkdir /media/vol1 /media/vol2
mount /dev/sdz1 /media/vol2 # intended vol1
btrfs resize -32G /media/vol1
umount
On Tue, Nov 18, 2014 at 02:39:48AM -0800, Robert White wrote:
Howdy,
How does one get the exact size (in blocks preferably, but bytes
okay) of the filesystem inside a partition? I know how to get the
partition size, but that's not useful when shrinking a partition...
So, for example, you
Le 18/11/2014 11:39, Robert White a écrit :
Howdy,
How does one get the exact size (in blocks preferably, but bytes okay)
of the filesystem inside a partition? I know how to get the partition
size, but that's not useful when shrinking a partition...
dev_item.total_bytes in
On 2014-11-18 02:29, 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 smartctl's output implies there
Chris Murphy posted on Mon, 17 Nov 2014 23:21:57 -0700 as excerpted:
I think we’re well past the expiration date on grub.cfg, a line should
be drawn in the sand to deprecate routine use of os-prober +
grub-mkconfig,
and move to drop-in scripts by whatever the distro presumes will be
Robert White posted on Tue, 18 Nov 2014 02:39:48 -0800 as excerpted:
How does one get the exact size (in blocks preferably, but bytes okay)
of the filesystem inside a partition? I know how to get the partition
size, but that's not useful when shrinking a partition...
There needs to be an
On 2014/11/18 09:36, Roman Mamedov wrote:
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
On 2014/11/18 14:08, Austin S Hemmelgarn wrote:
[snip] there are some parts of the drive that aren't covered by SMART
attributes on most disks, most notably the on-drive cache. There really isn't a
way to disable the read cache on the drive, but you can disable write-caching.
Its an old and
Brendan Hide posted on Tue, 18 Nov 2014 15:24:48 +0200 as excerpted:
In this case, yup, its directly to the motherboard chipset's built-in
ports. This is a very old desktop, and the other 3 disks don't have any
issues. I'm checking out the alternative pointed out by Austin.
SATA-relevant
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Please get in the habit of using your mail client's reply-to-all
button instead of reply; there is no need for us to take this
conversation private.
On 11/17/2014 10:15 PM, Fennec Fox wrote:
snip big smartctl output
i know the drive is dying and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2014 1:16 AM, Chris Murphy wrote:
If fstab specifies rootfs as UUID, and there are two volumes with
the same UUID, it’s now ambiguous which one at boot time is the
intended rootfs. It’s no different than the days of /dev/sdXY where
X
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2014 7:08 AM, Austin S Hemmelgarn wrote:
In addition to the storage controller being a possibility as
mentioned in another reply, there are some parts of the drive that
aren't covered by SMART attributes on most disks, most notably the
On 11/18/2014 02:13 AM, Liu Bo wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2014 10:35 AM, Marc MERLIN wrote:
Try running hdrecover on your drive, it'll scan all your blocks and
try to rewrite the ones that are failing, if any:
http://hdrecover.sourceforge.net/
He doesn't have blocks that are failing; he has
On Tue, Nov 18, 2014 at 11:04:00AM -0500, Phillip Susi wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2014 10:35 AM, Marc MERLIN wrote:
Try running hdrecover on your drive, it'll scan all your blocks and
try to rewrite the ones that are failing, if any:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2014 11:11 AM, Marc MERLIN wrote:
That seems to be the case, but hdrecover will rule that part out at
least.
It's already ruled out: if the read failed that is what the error
message would have said rather than a bad checksum.
-BEGIN
On Sat, Nov 15, 2014 at 01:27:13AM +, WorMzy Tykashi wrote:
I found a bit of a weird corner-case today. [1] It seems that, due to
the use of a 64-byte constant (ARGV0_BUF_SIZE) in utils.c, some tests
fail with a buffer overflow detected error if the progs are built in
a location with a
On Sun, Nov 09, 2014 at 03:54:56AM +, Duncan wrote:
A bit more context:
cmds-restore.c: In function 'next_leaf':
cmds-restore.c:182:20: warning: array subscript is above array bounds
[-Warray-bounds]
slot = path-slots[level] + 1;
^
Thanks. We've seen that before
I started experimenting with an 8 drive BTRFS RAID6, but rebalanced it a while
ago as RAID10. Recently though I’ve run into problems when trying to replace a
drive.
Nov 18 10:18:44 ganymede kernel: BTRFS warning (device sdk): dev_replace
cannot yet handle RAID5/RAID6
Even though df shows
On Nov 18, 2014, at 8:35 AM, Marc MERLIN m...@merlins.org wrote:
On Tue, Nov 18, 2014 at 09:29:54AM +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
On Nov 18, 2014, at 11:22 AM, Craig Yoshioka crai...@gmail.com wrote:
I started experimenting with an 8 drive BTRFS RAID6, but rebalanced it a
while ago as RAID10. Recently though I’ve run into problems when trying to
replace a drive.
Nov 18 10:18:44 ganymede kernel: BTRFS warning
On Nov 18, 2014, at 8:42 AM, Phillip Susi ps...@ubuntu.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2014 1:16 AM, Chris Murphy wrote:
If fstab specifies rootfs as UUID, and there are two volumes with
the same UUID, it’s now ambiguous which one at boot time is the
On 2014-11-18 07:21, Chris Murphy wrote:
Ergo just because I’ve snapshot my root does not mean grub-mkconfig
should be creating boot entries for it.
I find this an useful feature: a snapshot of / is done to rollback
some changes, so why don't let grub to start (the kernel) from ?
Anyway I find
2014-11-18 16:42 GMT+01:00 Phillip Susi ps...@ubuntu.com:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2014 1:16 AM, Chris Murphy wrote:
If fstab specifies rootfs as UUID, and there are two volumes with
the same UUID, it’s now ambiguous which one at boot time is the
intended
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2014 1:57 PM, Chris Murphy wrote:
So a.) use smartctl -l scterc to change the value below 30 seconds
(300 deciseconds) with 70 deciseconds being reasonable. If the
drive doesn’t support SCT commands, then b.) change the linux scsi
Liu Bo pointed out that my previous fix would lose the generation update in the
scenario I described. It is actually much worse than that, we could lose the
entire extent if we lose power right after the transaction commits. Consider
the following
write extent 0-4k
log extent in log tree
commit
On 11/18/2014 07:42 AM, Phillip Susi wrote:
On 11/18/2014 1:16 AM, Chris Murphy wrote:
(stuff about UUIDs and LVM snapshots).
(suggestion to use LVM paths instead).
This is also an XFS+LVM+LVM_Snapshot problem going back to at least
2009. It's inherent to the block-device-level snapshot
On Nov 18, 2014, at 1:58 PM, Phillip Susi ps...@ubuntu.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2014 1:57 PM, Chris Murphy wrote:
So a.) use smartctl -l scterc to change the value below 30 seconds
(300 deciseconds) with 70 deciseconds being reasonable. If the
Phillip Susi posted on Tue, 18 Nov 2014 15:58:18 -0500 as excerpted:
Are there really any that take longer than 30 seconds? That's enough
time for thousands of retries. If it can't be read after a dozen tries,
it ain't never gonna work. It seems absurd that a drive would keep
trying for so
So I finally figured out how to ask about this correctly.
As near as I can tell the difference between a subvolume created with
create and a subvolume created with snapshot is the existence of the
parent_uuid datum. Create has no parent, snapshot has the its
parent_uuid equal to the
On Nov 18, 2014, at 1:17 PM, Phillip Susi ps...@ubuntu.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2014 2:17 PM, Chris Murphy wrote:
What if you have a Btrfs raid1 volume using two LV’s and then
snapshot both LV’s?
That's even more silly than a single lvm
Phillip Susi posted on Tue, 18 Nov 2014 10:36:14 -0500 as excerpted:
As I said before though, the errors you posted from dmesg don't indicate
that the drive failed to read sectors, but rather that it returned
incorrect data, and this is *NEVER* supposed to happen.
I'd suggest running a few
Robert White posted on Tue, 18 Nov 2014 17:29:12 -0800 as excerpted:
On 11/18/2014 07:42 AM, Phillip Susi wrote:
On 11/18/2014 1:16 AM, Chris Murphy wrote:
(stuff about UUIDs and LVM snapshots).
(suggestion to use LVM paths instead).
This is also an XFS+LVM+LVM_Snapshot problem going
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
David Sterba posted on Tue, 18 Nov 2014 18:23:23 +0100 as excerpted:
On Sun, Nov 09, 2014 at 03:54:56AM +, Duncan wrote:
A bit more context:
cmds-restore.c: In function 'next_leaf':
cmds-restore.c:182:20: warning: array subscript is above array bounds
[-Warray-bounds]
slot =
On Mon, Nov 17, 2014 at 07:48:17AM -0800, Christoph Hellwig wrote:
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.
That seems reasonable. Using direct I/O
37 matches
Mail list logo
