Very low priority. No user data at risk. 8GB virtual disk being installed to, and the installer is puking. I''m trying to figure out why. I first get an rsync error 12, followed by the installer crashing. What''s interesting is this, deleting irrelevant source file systems, just showing the mounts for the installed system: [root@localhost tmp]# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda3 3746816 3193172 1564 100% /mnt/sysimage /dev/sda1 495844 31509 438735 7% /mnt/sysimage/boot /dev/sda3 3746816 3193172 1564 100% /mnt/sysimage/home So there''s 1.5M of free space left according to conventional df. However: [root@localhost tmp]# btrfs fi show Label: ''fedora_f18v'' uuid: 0c9b2b62-5ec1-4610-ab2f-9f00c909428a Total devices 1 FS bytes used 2.87GB devid 1 size 3.57GB used 3.57GB path /dev/sda3 [root@localhost tmp]# btrfs fi df /mnt/sysimage Data: total=2.69GB, used=2.69GB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=438.94MB, used=183.36MB Metadata: total=8.00MB, used=0.00 And absolutely nothing in dmesg. This is confusing. fi show says 3.57GB available and used. Whereas fi df says 2.69 available and used. So is it 3.57GB? Or is it 2.69? I suppose the simple answer is, it doesn''t matter, in either case it''s full. But it seems like the installer is underestimating Btrfs requirements and should be more conservative, somehow so I''d like to better understand the allocation. But then, of course, it''s a pretty small file system. This is a desktop installer, not embedded system, so the use case for an 8GB virtual disk itself calls into question the test perhaps. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jan 11, 2013 at 11:50 PM, Chris Murphy <lists@colorremedies.com> wrote:> Very low priority. > No user data at risk. > 8GB virtual disk being installed to, and the installer is puking. I''m trying to figure out why. > > I first get an rsync error 12, followed by the installer crashing. What''s interesting is this, deleting irrelevant source file systems, just showing the mounts for the installed system: > > [root@localhost tmp]# df > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/sda3 3746816 3193172 1564 100% /mnt/sysimage > /dev/sda1 495844 31509 438735 7% /mnt/sysimage/boot > /dev/sda3 3746816 3193172 1564 100% /mnt/sysimage/home > > So there''s 1.5M of free space left according to conventional df. However: > > [root@localhost tmp]# btrfs fi show > Label: ''fedora_f18v'' uuid: 0c9b2b62-5ec1-4610-ab2f-9f00c909428a > Total devices 1 FS bytes used 2.87GB > devid 1 size 3.57GB used 3.57GB path /dev/sda3 > > [root@localhost tmp]# btrfs fi df /mnt/sysimage > Data: total=2.69GB, used=2.69GB > System, DUP: total=8.00MB, used=4.00KB > System: total=4.00MB, used=0.00 > Metadata, DUP: total=438.94MB, used=183.36MB > Metadata: total=8.00MB, used=0.00 > > And absolutely nothing in dmesg. > > This is confusing. fi show says 3.57GB available and used. Whereas fi df says 2.69 available and used. So is it 3.57GB? Or is it 2.69? I suppose the simple answer is, it doesn''t matter, in either case it''s full. But it seems like the installer is underestimating Btrfs requirements and should be more conservative, somehow so I''d like to better understand the allocation.There reporting is correct, but a bit obscure. We have a FAQ item on how to read the output on the wiki, but it''s a known sore spot. btrfs fi show reports 3.57GB allocated to block groups (so everything is assigned to metadata or data); btrfs fi df reports how that 3.57GB is being used: of 2.69GB allocated to data block groups, 2.69GB (i.e., all of it) is in use by file data; of 438.94MB of metadata (or 0.87GB after DUP), 183.36MB is in use by metadata (which may include small files that have been inlined). In other words, the tools are saying that filesystem is basically full. :) Note that the -M option to mkfs.btrfs is intended for this use-case: filesystems where the size of a block allocation is large compared to the size of the filesystem. It should let you squeeze out most of the rest of that 400MB (200MB, DUP). -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Jan 11, 2013, at 11:04 PM, cwillu <cwillu@cwillu.com> wrote:> On Fri, Jan 11, 2013 at 11:50 PM, Chris Murphy <lists@colorremedies.com> wrote: >> Very low priority. >> No user data at risk. >> 8GB virtual disk being installed to, and the installer is puking. I''m trying to figure out why. >> >> I first get an rsync error 12, followed by the installer crashing. What''s interesting is this, deleting irrelevant source file systems, just showing the mounts for the installed system: >> >> [root@localhost tmp]# df >> Filesystem 1K-blocks Used Available Use% Mounted on >> /dev/sda3 3746816 3193172 1564 100% /mnt/sysimage >> /dev/sda1 495844 31509 438735 7% /mnt/sysimage/boot >> /dev/sda3 3746816 3193172 1564 100% /mnt/sysimage/home >> >> So there''s 1.5M of free space left according to conventional df. However: >> >> [root@localhost tmp]# btrfs fi show >> Label: ''fedora_f18v'' uuid: 0c9b2b62-5ec1-4610-ab2f-9f00c909428a >> Total devices 1 FS bytes used 2.87GB >> devid 1 size 3.57GB used 3.57GB path /dev/sda3 >> >> [root@localhost tmp]# btrfs fi df /mnt/sysimage >> Data: total=2.69GB, used=2.69GB >> System, DUP: total=8.00MB, used=4.00KB >> System: total=4.00MB, used=0.00 >> Metadata, DUP: total=438.94MB, used=183.36MB >> Metadata: total=8.00MB, used=0.00 >> >> And absolutely nothing in dmesg. >> >> This is confusing. fi show says 3.57GB available and used. Whereas fi df says 2.69 available and used. So is it 3.57GB? Or is it 2.69? I suppose the simple answer is, it doesn''t matter, in either case it''s full. But it seems like the installer is underestimating Btrfs requirements and should be more conservative, somehow so I''d like to better understand the allocation. > > There reporting is correct, but a bit obscure. We have a FAQ item on > how to read the output on the wiki, but it''s a known sore spot. > > btrfs fi show reports 3.57GB allocated to block groups (so everything > is assigned to metadata or data); btrfs fi df reports how that 3.57GB > is being used: of 2.69GB allocated to data block groups, 2.69GB (i.e., > all of it) is in use by file data; of 438.94MB of metadata (or 0.87GB > after DUP), 183.36MB is in use by metadata (which may include small > files that have been inlined).So if I assume 2.7GiB for data, and add up the left side of fi df I get 3224MB rounded up, which is neither 3.57GB or 3.57GiB. I''m missing 346MB at least. That is what I should have said from the outset. So is the Metadta DUP Total 438.94MB allocated value actually twice that, but only 438.94MB is displayed because that''s what''s available (since the metadata is duplicated)?> > In other words, the tools are saying that filesystem is basically full. :)Right yes, very clear!> > Note that the -M option to mkfs.btrfs is intended for this use-case: > filesystems where the size of a block allocation is large compared to > the size of the filesystem. It should let you squeeze out most of the > rest of that 400MB (200MB, DUP).Is there a simple rule of thumb an installer could use to know when to use -M? I know mkfs.btrfs will do this for smaller filesystems than this. I''m thinking this is a testing edge case that a desktop installer shouldn''t be concerned about, but rather should just gracefully fail from, or better yet, insist on a larger install destination than this in particular when Btrfs. Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> [root@localhost tmp]# df >>> Filesystem 1K-blocks Used Available Use% Mounted on >>> /dev/sda3 3746816 3193172 1564 100% /mnt/sysimage >>> /dev/sda1 495844 31509 438735 7% /mnt/sysimage/boot >>> /dev/sda3 3746816 3193172 1564 100% /mnt/sysimage/home >>> >>> So there''s 1.5M of free space left according to conventional df. However: >>> >>> [root@localhost tmp]# btrfs fi show >>> Label: ''fedora_f18v'' uuid: 0c9b2b62-5ec1-4610-ab2f-9f00c909428a >>> Total devices 1 FS bytes used 2.87GB >>> devid 1 size 3.57GB used 3.57GB path /dev/sda3 >>> >>> [root@localhost tmp]# btrfs fi df /mnt/sysimage >>> Data: total=2.69GB, used=2.69GB >>> System, DUP: total=8.00MB, used=4.00KB >>> System: total=4.00MB, used=0.00 >>> Metadata, DUP: total=438.94MB, used=183.36MB >>> Metadata: total=8.00MB, used=0.00> So if I assume 2.7GiB for data, and add up the left side of fi df I get 3224MB rounded up, which is neither 3.57GB or 3.57GiB. I''m missing 346MB at least. That is what I should have said from the outset.2.69 + (438.94 / 1000 *2) + (8.0 / 1000 / 1000 *2) + (4.0 / 1000 / 1000) + (8.0 / 1000 / 1000 *2) 3.567916 Looks like 3.57GB to me :p> So is the Metadta DUP Total 438.94MB allocated value actually twice that, but only 438.94MB is displayed because that''s what''s available (since the metadata is duplicated)?The capacity of the metadata group is 438.94; the actual size on disk is twice that.>> Note that the -M option to mkfs.btrfs is intended for this use-case: >> filesystems where the size of a block allocation is large compared to >> the size of the filesystem. It should let you squeeze out most of the >> rest of that 400MB (200MB, DUP). > > Is there a simple rule of thumb an installer could use to know when to use -M? I know mkfs.btrfs will do this for smaller filesystems than this. I''m thinking this is a testing edge case that a desktop installer shouldn''t be concerned about, but rather should just gracefully fail from, or better yet, insist on a larger install destination than this in particular when Btrfs.I tend to go with "any filesystem smaller than 32GB", but a more accurate rule is probably along the lines of "any filesystem that you expect to normally run within half a gb of full". -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Jan 12, 2013, at 12:48 AM, cwillu <cwillu@cwillu.com> wrote:>>>> [root@localhost tmp]# btrfs fi df /mnt/sysimage >>>> Data: total=2.69GB, used=2.69GB >>>> System, DUP: total=8.00MB, used=4.00KB >>>> System: total=4.00MB, used=0.00 >>>> Metadata, DUP: total=438.94MB, used=183.36MB >>>> Metadata: total=8.00MB, used=0.00 > >> So if I assume 2.7GiB for data, and add up the left side of fi df I get 3224MB rounded up, which is neither 3.57GB or 3.57GiB. I''m missing 346MB at least. That is what I should have said from the outset. > > 2.69 + (438.94 / 1000 *2) + (8.0 / 1000 / 1000 *2) + (4.0 / 1000 / > 1000) + (8.0 / 1000 / 1000 *2) > 3.567916 > > Looks like 3.57GB to me :p > >> So is the Metadta DUP Total 438.94MB allocated value actually twice that, but only 438.94MB is displayed because that''s what''s available (since the metadata is duplicated)? > > The capacity of the metadata group is 438.94; the actual size on disk > is twice that.OK, got it. However, this is a significant linguistic problem to use the presence of a qualifier on the words total and used in such a very non-obvious manner, to your point that it''s obscure and a known sore spot. It constitutes a secret decoder ring. Look at it this way. Case 1: Metadata, DUP: total=438.94MB, used=183.36MB Case 2: Metadata: total=438.94MB, used=183.36MB The df command means "file system disk space usage". It doesn''t mean "capacity of blah group". The capacity of the metadata group is a matter of trivia. I think in a df command, the numeric values need to be true to the command. And to do that, the values in case 1 should be twice that of the values in case 2. But this isn''t just a sore spot here, this is a concern in the broader conversation of how to show used and free space on Btrfs in general, in particular as it gets raid5/6, and eventually per subvolume (and per file?) data profiles. There is a long history of showing literal file sizes, rather than their resource allocation. I think that''s the problem. ls -l will show me a 500000000 byte sparse file of zeros as being 500000000 bytes. That''s true, but I''ll argue pretty much all users of computers, most of the time, want to know the resource allocation of the file. That sparse file has a very different resource allocation than 477MiB. Likewise a non-zero file of the same size, compressed vs not-compressed? It''s 477MiB of data in either case, if that''s what''s meant by "file size" but clearly the resource allocation "file size" is different, compressed or not compressed. If the file''s data profile is raid0, raid1, raid5, or raid6, those are four different amounts of resource consumption by the same file. Yet ls -lh will show me 477 MiB in any case. ls -ls tries to do better in the compression case, but it fails in the raid case. OK, I''ve diverted. Thank you for the explanation.> I tend to go with "any filesystem smaller than 32GB", but a more > accurate rule is probably along the lines of "any filesystem that you > expect to normally run within half a gb of full".Both are good rules of thumb. Thanks. Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html