Still running 3.10-3-rpi alas because there isn't a 3.14.15 :) version of the pi kernel yet, but is an increasing latency as the uptime increases, expected? Reboot the kernel, and I go back to having 0.1second latency on my SD card in the pi. But after a few weeks, it will be back to 2 second latencies: http://rather.puzzling.org/munin-cgi/pi/pi/diskstats_latency/mmcblk0.html (it started exhibiting this behaviour after the last reboot in January because that's when I installed a btrfs capable kernel and ran ext3tobtrfs over it. Yes, I've deleted the ext3 image snapshot) -- Tim Connors
Hey, On 4 Apr 2014, at 9:33 pm, Tim Connors <tconnors@rather.puzzling.org> wrote:
Still running 3.10-3-rpi alas because there isn't a 3.14.15 :) version of the pi kernel yet, but is an increasing latency as the uptime increases, expected?
What parameters did you use for mkfs.btrfs? What are your fstab mount options? Does btrfs detect non-spinning media, i.e. use the SSD options automatically?
On Sat, 5 Apr 2014, Avi Miller wrote:
Hey,
On 4 Apr 2014, at 9:33 pm, Tim Connors <tconnors@rather.puzzling.org> wrote:
Still running 3.10-3-rpi alas because there isn't a 3.14.15 :) version of the pi kernel yet, but is an increasing latency as the uptime increases, expected?
What parameters did you use for mkfs.btrfs? What are your fstab mount options? Does btrfs detect non-spinning media, i.e. use the SSD options automatically?
grep btr /etc/fstab /dev/mmcblk0p2 / btrfs defaults,relatime,ssd_spread,discard,space_cache,autodefrag,inode_cache,compress 0 1 grep btr /proc/mounts /dev/mmcblk0p2 / btrfs rw,relatime,compress=zlib,ssd_spread,discard,space_cache,autodefrag,inode_cache 0 0
Lost the commandline history around the conversion, but I believe it was just btrfs-convert /dev/mmcblk0p2 Tried to rebalance and/or defrag once after the conversion, but kernel 3.10 kernel panics. /sys/block/mmcblk0/queue/rotational = 0 Where/what package is mount.btrfs's manpage in debian? No idea whether btrfs has actually detected it's not spinning. -- Tim Connors
Hey, On 5 Apr 2014, at 11:36 am, Tim Connors <tconnors@rather.puzzling.org> wrote:
/dev/mmcblk0p2 / btrfs defaults,relatime,ssd_spread,discard,space_cache,autodefrag,inode_cache,compress 0 1
My advice: switch relatime to noatime, and remove discard (not used on MMC/SD) and inode_cache. I’d also recommend removing the compress option, because I’m betting the Pi is suffering under the compression calculations.
Where/what package is mount.btrfs's manpage in debian? No idea whether btrfs has actually detected it's not spinning.
No idea where the manpage is on Debian, but https://btrfs.wiki.kernel.org/index.php/Main_Page is your friend. :) Also http://manpages.ubuntu.com/manpages/quantal/man8/mkfs.btrfs.8.html The rotational = 0 means it’s non-spinning, so that’s fine. However, the default btrfs conversion would switch to duplicated metadata with single data. You possibly also don’t have inline/mixed on the SD, which means you have separate metadata and data block assignment. The fact that a rebalance panics the kernel is worrying, because I would’ve recommended rebalancing to single data and metadata. If it’s possible, I’d actually reformat completely in mixed-mode, with single for both data and metadata, ie. pass “-M -m single -d single” Though, I’d still strongly recommend upgraded to a 3.13 kernel, if possible. Cheers, Avi
Avi Miller <avi.miller@gmail.com> writes:
The rotational = 0 means it’s non-spinning, so that’s fine.
Does this change anything *other than* making -o ssd the default? My onboard m.2 correctly declaims rotational=0, but my SD card reader doesn't.
However, the default btrfs conversion would switch to duplicated metadata with single data. You possibly also don’t have inline/mixed on the SD, which means you have separate metadata and data block assignment.
You can check this way (I think): $ sudo btrfs fi df / System, single: total=4.00MiB, used=4.00KiB Data+Metadata, single: total=9.01GiB, used=7.98GiB Not sure how to check for --metadata dup vs. --metadata single.
The fact that a rebalance panics the kernel is worrying, because I would’ve recommended rebalancing to single data and metadata.
Use netconsole to see what the printks are at panic time? (Assuming you can't just read that off the serial port, or whatever rpis have.)
If it’s possible, I’d actually reformat completely in mixed-mode, with single for both data and metadata, ie. pass “-M -m single -d single”
Strongly agree (for volumes <<1TiB, which an MMC surely is).
trentbuck@gmail.com (Trent W. Buck) writes:
You can check this way (I think):
$ sudo btrfs fi df / System, single: total=4.00MiB, used=4.00KiB Data+Metadata, single: total=9.01GiB, used=7.98GiB
Not sure how to check for --metadata dup vs. --metadata single.
Derp. It says "single" right there in the transcript.
On Mon, 7 Apr 2014 05:11:30 PM Trent W. Buck wrote:
Avi Miller <avi.miller@gmail.com> writes:
The rotational = 0 means it’s non-spinning, so that’s fine.
Does this change anything *other than* making -o ssd the default?
Doesn't appear to, no. if (!btrfs_test_opt(tree_root, SSD) && !btrfs_test_opt(tree_root, NOSSD) && !fs_info->fs_devices->rotating) { printk(KERN_INFO "BTRFS: detected SSD devices, enabling SSD " "mode\n"); btrfs_set_opt(fs_info->mount_opt, SSD); } That fs-devices->rotating variable is populated when initialising or opening a btrfs device by something like: · if (!blk_queue_nonrot(bdev_get_queue(bdev))) . · root->fs_info->fs_devices->rotating = 1; cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
On Mon, 7 Apr 2014, Chris Samuel wrote:
On Mon, 7 Apr 2014 05:11:30 PM Trent W. Buck wrote:
Avi Miller <avi.miller@gmail.com> writes:
The rotational = 0 means it’s non-spinning, so that’s fine.
Does this change anything *other than* making -o ssd the default?
Doesn't appear to, no.
if (!btrfs_test_opt(tree_root, SSD) && !btrfs_test_opt(tree_root, NOSSD) && !fs_info->fs_devices->rotating) { printk(KERN_INFO "BTRFS: detected SSD devices, enabling SSD " "mode\n"); btrfs_set_opt(fs_info->mount_opt, SSD); }
That fs-devices->rotating variable is populated when initialising or opening a btrfs device by something like:
· if (!blk_queue_nonrot(bdev_get_queue(bdev))) . · root->fs_info->fs_devices->rotating = 1;
I wonder if a fibre channel SAN gets marked as "non rotating"? It might be rotating today, and non-rotating tomorrow when the data is a bit hotter. I notice there's a lot of static tests in filesystem/RAID code that should be checked dynamically. I remember the 512 BIO bug that affects LVM/mdadm - add a USB disk to a raid array, and ext3 spits out warnings only because it falls back and does the right thing (albeit very slowly) when requests fail. But all the other FSs corrupt data instead. Oh looky here, a very similar bug to the one I reported upstream: https://bugzilla.redhat.com/show_bug.cgi?id=648885 -- Tim Connors
On 7 Apr 2014, at 8:53 pm, Tim Connors <tconnors@rather.puzzling.org> wrote:
I wonder if a fibre channel SAN gets marked as "non rotating"? It might be rotating today, and non-rotating tomorrow when the data is a bit hotter.
It does and it doesn’t, depending on the HBA. Also, Xen Virtual Disks are marked as non-rotating too, which may or may not be true, hence it’s worth checking and setting nossd on the devices that are actually rotating. Cheers, Avi
Tim Connors <tconnors@rather.puzzling.org> writes:
On Mon, 7 Apr 2014, Chris Samuel wrote:
That fs-devices->rotating variable is populated when initialising or opening a btrfs device by something like:
· if (!blk_queue_nonrot(bdev_get_queue(bdev))) . · root->fs_info->fs_devices->rotating = 1;
I wonder if a fibre channel SAN gets marked as "non rotating"? It might be rotating today, and non-rotating tomorrow when the data is a bit hotter.
OBVIOUSLY the SAN doesn't rotate, even if its disks do :-P Modulo the Earth's rotation &c.
participants (4)
-
Avi Miller -
Chris Samuel -
Tim Connors -
trentbuck＠gmail.com