| To: | Jan Engelhardt <jengelh@xxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: Volume too big |
| From: | Eric Sandeen <sandeen@xxxxxxxxxxx> |
| Date: | Sat, 19 Jan 2008 15:26:26 -0600 |
| Cc: | xfs@xxxxxxxxxxx |
| In-reply-to: | <Pine.LNX.4.64.0801192200390.4780@fbirervta.pbzchgretzou.qr> |
| References: | <Pine.LNX.4.64.0801191650260.4780@fbirervta.pbzchgretzou.qr> <4792223E.7080805@sandeen.net> <Pine.LNX.4.64.0801191808100.4780@fbirervta.pbzchgretzou.qr> <47926087.3020600@sandeen.net> <Pine.LNX.4.64.0801192200390.4780@fbirervta.pbzchgretzou.qr> |
| Sender: | xfs-bounce@xxxxxxxxxxx |
| User-agent: | Thunderbird 2.0.0.9 (Macintosh/20071031) |
Jan Engelhardt wrote: > On Jan 19 2008 14:41, Eric Sandeen wrote: >> It's possible that btrfs can cope with this somehow - but also quite >> possible that it's just missing the right checks :) >> > I am not sure why Linux would be limited to 16 TB. If LBD is on, > things are 64 bit, so I would expect to have at least access to > 2 exabyte. 64-bit sector addressing, but there is a 32-bit index into the (4k) pagecache. 2^32 * 4096 is 16T So an address space has a 16T limit. Even mkfs, if it needs to write past 16T (and I think mkfs.btrfs doesn't need that...) will have trouble, if the device is > 16T - unless mkfs uses direct IO. -Eric |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Volume too big, Jan Engelhardt |
|---|---|
| Next by Date: | Re: Volume too big, Eric Sandeen |
| Previous by Thread: | Re: Volume too big, Jan Engelhardt |
| Next by Thread: | Re: Volume too big, Eric Sandeen |
| Indexes: | [Date] [Thread] [Top] [All Lists] |