From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs on whole disk (no partitions)
Date: Mon, 23 Jun 2014 02:10:03 +0000 (UTC) [thread overview]
Message-ID: <pan$600a2$3927cc39$ae007590$e90b8415@cox.net> (raw)
In-Reply-To: 99AD3EFE-AF9A-44A1-912E-07B1E934239B@colorremedies.com
Chris Murphy posted on Sun, 22 Jun 2014 12:47:10 -0600 as excerpted:
>> As far as I know, btrfs defaults to 4K UNLESS you specify 512B
>
> I'm not sure what this means. The Btrfs sector size minimum is 4096
> bytes.
> I can use -s to make it bigger, but not less than 4096 on 512/512 or
> 512/4096 byte drives. I actually don't know what Btrfs sector size is
> but it's not the same thing as drive logical or physical sector size.
FWIW, for btrfs I prefer the terms block size or page size, which on x86
(both 32-bit and 64-bit) and arm is 4096 bytes (tho on other archs it can
range from 2048 byte to 64 KiB), reserving the "sector" term for actual
hardware.
Btrfs is copy-on-write, and AFAIK sends no operations to the lower levels
at smaller than this block size, so on x86 (32-bit or 64-bit), all btrfs
level operations should be in 4096-byte increments, regardless of the
underlying ATA/SCSI hardware.
Tho as you point out elsewhere, levels under the filesystem layer may
split the btrfs 4096 byte block size into 512 byte logical sector sizes
if appropriate, but that has nothing to do with btrfs except that it
operates on top of that.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2014-06-23 2:10 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-18 19:29 btrfs on whole disk (no partitions) Daniel Cegiełka
2014-06-18 20:10 ` Chris Murphy
2014-06-19 11:15 ` Austin S Hemmelgarn
2014-06-18 21:19 ` Imran Geriskovan
2014-06-19 0:07 ` Russell Coker
2014-06-19 8:58 ` Imran Geriskovan
2014-06-19 9:11 ` Imran Geriskovan
2014-06-21 19:19 ` Daniel Cegiełka
2014-06-22 1:36 ` Chris Murphy
2014-06-21 19:12 ` Daniel Cegiełka
2014-06-22 1:34 ` Chris Murphy
2014-06-22 7:49 ` Imran Geriskovan
2014-06-22 13:44 ` George Mitchell
2014-06-22 14:11 ` Roman Mamedov
2014-06-22 14:41 ` George Mitchell
2014-06-22 14:46 ` George Mitchell
2014-06-22 18:56 ` Chris Murphy
2014-06-22 18:47 ` Chris Murphy
2014-06-23 2:10 ` Duncan [this message]
2014-06-23 12:24 ` Martin K. Petersen
2014-06-24 5:37 ` Duncan
2014-06-25 13:01 ` Imran Geriskovan
2014-06-25 16:01 ` Duncan
2014-06-26 18:26 ` Imran Geriskovan
2014-06-26 18:41 ` Chris Murphy
2014-06-26 20:46 ` Imran Geriskovan
2014-06-22 18:31 ` Chris Murphy
2014-06-23 11:34 ` Martin K. Petersen
2014-06-19 1:01 ` George Mitchell
2014-06-19 4:52 ` Russell Coker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$600a2$3927cc39$ae007590$e90b8415@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.