Is there a performance advantage in using Btrfs subvolumes over raw (MBR/GPT) partitions on rotational disks?
Let's say I use a 128GiB MBR partition for OS and remaining 800GiB+ on disk serves another purpose. Then all OS files will be physically close to each other on the disk, thus reducing seek times. If I use the whole disk for OS partition, then files will be spread across the disk and even OS-only operations will require hard drive heads to perform longer seeks. What effect have Btrfs subvolumes in this case if I use them instead of MBR partitions? Btrfs wiki says: "btrfs does write optimisation (sequential writes) across a filesystem", "subvolume write performance will benefit from this algorithm". I don't understand what it means and couldn't find explanation. Does Btrfs optimize file data placement on rotational disk inside single subvolume, so that storing similar (accessed together) data inside single subvolume will benefit in terms of performance? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Does data checksumming remain for files with No_COW file attribute?
There is an unanswered question at stackexchange: http://unix.stackexchange.com/q/303130/41572 Assume that we don't invoke mount options like nodatacow and nodatasum - operate only at file attributes level, which are controlled with lsattr/chattr. So does setting No_COW on a file (chattr +C) imply disabling data checksumming on it? The same way as mount options behave (nodatacow implies nodatasum)? Moreover may it disable checksumming only for newly written extents and keep for reading existing ones? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Does data checksumming remain for files with No_COW file attribute?
Ok, so data checksumming does not remain for newly created empty files with No_COW attribute. I think it's an important trait of Btrfs behavior and should be added to wiki. So that users are informed that disabling CoW on a per-file basis also loses checksum correctness of such file. 24.09.2016, 15:37, "Hugo Mills" : > On Sat, Sep 24, 2016 at 03:26:14PM +0300, Alexander Tomokhov wrote: >> There is an unanswered question at stackexchange: >> http://unix.stackexchange.com/q/303130/41572 >> >> Assume that we don't invoke mount options like nodatacow and nodatasum - >> operate only at file attributes level, which are controlled with >> lsattr/chattr. So does setting No_COW on a file (chattr +C) imply disabling >> data checksumming on it? The same way as mount options behave (nodatacow >> implies nodatasum)? Moreover may it disable checksumming only for newly >> written extents and keep for reading existing ones? > > Yes, it does imply disabling checksums. > > If you have extents in the file when +C is set, then the flag is > ignored (even for new extents, as far as I know): you can only > usefully set +C on a file with no extents. > > So, to use +C, you either need to touch the file first, then set +C > on it, then open the file and write to it, or you need to have +C set > on the parent directory. > > Hugo. > >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > Hugo Mills | Comic Sans goes into a bar, and the barman says, "We > hugo@... carfax.org.uk | don't serve your type here." > http://carfax.org.uk/ | > PGP: E2AB1DE4 | -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Is it possible to have metadata-only device with no data?
Is it possible, having two drives to do raid1 for metadata but keep data on a single drive only? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is it possible to have metadata-only device with no data?
Thank you. Interesting. At least it's possible to implement in theory. Though, this way metadata-only device is still handled like a casual btrfs device and not distinguished separately from normal data+metadata devices. 06.02.2017, 02:54, "Roman Mamedov" : > On Sun, 5 Feb 2017 22:55:42 +0100 > Hans van Kranenburg wrote: > >> On 02/05/2017 10:42 PM, Alexander Tomokhov wrote: >> > Is it possible, having two drives to do raid1 for metadata but keep data >> on a single drive only? >> >> Nope. >> >> Would be a really nice feature though... Putting metadata on SSD and >> bulk data on HDD... > > You can play around with this hack just to see how that would perform, but it > comes with no warranty and untested even by me. I was going to try it, but put > it on hold since you'd also need to make sure the SSD is being preferred for > metadata reads (and not HDD), but so far have not figured out a simple way of > ensuring that. > > --- linux-amd64-4.4/fs/btrfs/volumes.c.orig 2016-11-01 22:41:41.970978721 > +0500 > +++ linux-amd64-4.4/fs/btrfs/volumes.c 2016-11-01 22:58:45.958977731 +0500 > @@ -4597,6 +4597,14 @@ > if (total_avail == 0) > continue; > > + /* If we have two devices and one is less than 25% of the total FS size, > then > + * presumably it's a small device just for metadata RAID1, don't use it > + * for new data chunks. */ > + if ((fs_devices->num_devices == 2) && > + (device->total_bytes * 4 < fs_devices->total_rw_bytes) && > + (type & BTRFS_BLOCK_GROUP_DATA)) > + continue; > + > ret = find_free_dev_extent(trans, device, > max_stripe_size * dev_stripes, > &dev_offset, &max_avail); > > -- > With respect, > Roman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is it possible to have metadata-only device with no data?
Yeah, thank you for suggestion. Bcache is what I actually use right now. However it's concept is different, operating at block/bucket level and requires another (underlying!) layer. 06.02.2017, 01:27, "Kai Krakow" : > Am Mon, 06 Feb 2017 00:42:01 +0300 > schrieb Alexander Tomokhov : > >> Is it possible, having two drives to do raid1 for metadata but keep >> data on a single drive only? -- > > No, but you could take a look into bcache which should get you > something similar if used in write-around mode. > > Random access will become cached in bcache, which should most of the > time be metadata, plus of course randomly accessed data from HDD. If > you reduce the sequential cutoff trigger in bcache, it should cache > mostly metadata only. > > -- > Regards, > Kai > > Replies to list-only preferred. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
