I am trying to make a disk image of a 160GB drive. The terminal command I used was:
dd bs=2M of=/Data_Backup/Drive.Image if=/dev/disk/ata/0/slave/raw
The copy fails after 138787422208 bytes (139 GB) are written with an error of ‘File too large’
Is this a limitation of the DD program or the BFS used by Haiku?
Just finished testing the use of the command:
cp /dev/disk/ata/0/slave/raw /Data_Backup/Drive.Image
This failed at 128.3GB with the same error message. Because the size is smaller and it is the same 250GB drive used both times I have to consider the possibility the the other 99GB of files still on the drive (more had been erased) are fragmenting the allocation chain runs.
I will backup/format the drive and test again.
Just finished testing the use of the command:
cp /dev/disk/ata/0/slave/raw /Data_Backup/Drive.Image
This failed at 128.3GB with the same error message. Because the size is smaller and it is the same 250GB drive used both times I have to consider the possibility the the other 99GB of files still on the drive (more had been erased) are fragmenting the allocation chain runs.
I will backup/format the drive and test again.
So it seems a BFS file size limitations ? BFS use a int32 (long) for the inode DB?
I’d supose it’s to fill a bug on track (maybe this is not a bug, but an enchantment more correctly?)
So it’s written where DEVs read for real…
http://en.wikipedia.org/wiki/BEFS states:
Whilst intended as a 64-bit capable file system, the size of some on-disk structures mean that practical size limit is approximately 2 exabytes. Similarly the extent based file allocation reduces the maximum practical file size to approximately 260 gigabytes at best and as little as a few blocks in a pathological worst case, depending on the degree of fragmentation.
One can only assume that the block size can also have an impact on the maximum file size.
Okay tested and failed on a newly formatted drive partition. (450GB) The same error after 139 GBs were written.
I have now reformatted the partition with a block size of 8192 bytes. All other
previous tests were with a block size of 2048 bytes which is the normal default. I will report the results in about an hour.
Okay, with the partition formatted with 8192 byte blocks the entire drive did copy.
So if you need very large files you need to not use the defaults when formatting your drive.
OK, so I’d suggest to open an enhancement ticket for this… 8192 should be the default or if drive > 400 GB Haiku should auto-select 8192 , right?
Small disagreement, 4096 bytes is the true block size of SSDs and newer large hard drives. I am sure if I did the test again that it would also work with 4096 byte blocks as this means the data blocks, indirect blocks and the indirect-indirect blocks all double in size, on a simple guess that would limit you to a file eight(8) times larger or just over a Terabyte.
Best guess to format for drive sizes:
drives < 256 GigaByte 2048 byte blocks.
drives < 1-2 TeraByte 4096 byte blocks.
drives >>> 2 TeraByte 8192 byte blocks.
Practical File System Design:The Be File System, by Dominic Giampaolo page 55
If I am reading it right, note I still have to figure out data extents:
1024 Bytes Blocks:
12 Direct Blocks = 12K of data.
128 Indirect Blocks = 128K of data.
16384 Double-Indirect Blocks = 16,384K of data.
Max file size is 16524K or 16,920,576 bytes.
2048 Bytes Blocks:
12 Direct Blocks = 24K of data.
256 Indirect Blocks = 512K of data.
65536 Double-Indirect Blocks = 131,072K of data.
Max file size 131,608K or 134,766,592 bytes.
4096 Bytes Blocks:
12 Direct Blocks = 48K of data.
512 Indirect Blocks = 2048K of data.
262144 Double-Indirect Blocks = 1,048,576K of data.
Max file size 1,050,672K or 1,075,888,128 bytes.
8192 Bytes Blocks:
12 Direct Blocks = 96K of data.
1024 Indirect Blocks = 8192K of data.
1048576 Double-Indirect Blocks = 8,388,608K of data.
Max file size 8,396,896K or 8,598,421,504 bytes.
Extents are what I need to figure out next. But we can already see that as the block size doubles the max file more than doubles.
Forget what I posted above, I misread the i-node structure. The pointers are to block-run not data blocks. I need to start over.
Forget what I posted above, I misread the i-node structure. The pointers are to block-run not data blocks. I need to start over.
Forget what I posted above, I misread the i-node structure. The pointers are to block-run not data blocks. I need to start over.
I still have an older thread to catch up on when I get a chance, but it so happens that I did all the calculations Earl is interested in some time ago, and I can dig them out.
On “large” (by BeOS standards, ie mid-1990s) disks the BFS allocation group size is always 65536 fs blocks. So this will always be true for any modern disk or a reasonable sized partition of such a disk.
Each BFS file has 12 direct runs, an indirect run and a doubly-indirect run. Each direct run can point to one contiguous portion of an allocation group with a 16-bit length. So long as there is little or no fragmentation this will be 65535 fs blocks.
So for 1024 byte blocks the direct runs add up to 805294080 bytes, and with 8192 byte blocks it is 6442352640 bytes
The indirect run consists of a run of 4 contiguous blocks from an allocation group, which in turn contains more block runs like the 12 direct runs. For 1024 byte blocks 512 such runs will fit, for 8192 byte blocks it’s 4096 runs. So the total from this part of the file’s allocation is up to 34359214080 bytes for 1024 byte blocks and 2198989701120 bytes with 8192 byte blocks.
However the doubly indirect run consists of a run of 4 contiguous blocks from an allocation group, but which in turn contains block runs that are themselves pointing to 4 contiguous blocks from an allocation group, and then those in turn each contain a series of block runs of exactly 4 blocks that are used for data. So for 1024 byte blocks there are 262144 such data runs, giving a total of 1073741824 bytes, and for 8192 byte blocks it is 16777216 runs totalling 549755813888 bytes.
( If any of the intermediate structures cannot be allocated due to fragmentation, growing the file fails, although plenty of space may remain for other operations. )
So that comes to 33.7 GiB for 1024 byte blocks and 2.5 TiB for 8192 byte blocks.
For today’s largest single SATA drives this isn’t necessarily enough to make a disk image even with the 8192 byte block size. It probably makes sense just to mention it in the documentation as a limitation and leave the default block sizes alone.
This is quite a contrast from a traditional Unix filesystem where the bulk of a very large file is in the double (or triple) indirect blocks, in BFS the double indirect doesn’t actually achieve very much except blunting the impact of mild fragmentation.
I have to read the book some more, but I was sure there was a way to increase the run of 4 contiguous blocks. If not few people will run into a problem for the next 2-3 years if they use 8192 blocks.
At the very least, the idea of basing the size of the run based on the size of the partition formatted can be consider for R1/R2. The ‘inode magic numbers’ can also be used so that old versions of BFS will not try to write to the newer formatted partition.
PS: Thanks NoHaikuForMe for doing the math.
Upon inspection, you are correct, Axel modified Haiku’s BFS implementation a while back so that it’s possible for a future BFS implementation to use larger block runs for double indirect blocks, without losing compatibility (but all the double indirect runs in a particular file must remain the same size). In fact he also changed the default so that it varies by block size, which my calculations above do not account for, and which to my understanding reduces the maximum file size somewhat for 8192 byte blocks over the figures given above.
Increasing the block run count trades vulnerability to fragmentation to gain maximum file size, with very large block runs BFS could handle files far larger than any single SATA drive available today, but at the risk that even mild fragmentation would cause trouble. At smaller sizes fragmentation won’t tend to cause problems until the disk is very full but maximum file sizes would be restricted. So (in BFS at any rate) a balance must be sought.
Your numbers were a little off for 1024 byte blocks.
My Test:
~> dd bs=1M if=/dev/zero of=/Haiku/Test
dd: writing `/Haiku/Test’: File too large
34291+0 records in
34290+0 records out
35955671040 bytes (36 GB) copied, 923.648 s, 38.9 MB/s
When I have time I will create a virtual 4TB drive and test that out too.
Your numbers were a little off for 1024 byte blocks.
My Test:
~> dd bs=1M if=/dev/zero of=/Haiku/Test
dd: writing `/Haiku/Test’: File too large
34291+0 records in
34290+0 records out
35955671040 bytes (36 GB) copied, 923.648 s, 38.9 MB/s
When I have time I will create a virtual 4TB drive and test that out too.
Your numbers were a little off for 1024 byte blocks.
My Test:
~> dd bs=1M if=/dev/zero of=/Haiku/Test
dd: writing `/Haiku/Test’: File too large
34291+0 records in
34290+0 records out
35955671040 bytes (36 GB) copied, 923.648 s, 38.9 MB/s
When I have time I will create a virtual 4TB drive and test that out too.
Brother:
35955671040 / ( 1024 * 1024 *1024 ) = 33.486328125 GB
I should not have trusted DD, the numbers don’t match still but the diffirence is very minor.