Re: Cannot Deinstall a Debian Package
Chris Mason wrote (ao): I'm happy to patch up bugs in the FS (or point you to newer kernels that have them fixed) but at this point we don't have enough info to say if it is an FS problem or a debian package problem. Perhaps if you ran it under strace? Other distros don't have problems with btrfs on /, so somehow this is specific to debian's setup. I believe this is fixed in Debian testing/unstable: http://packages.debian.org/changelogs/pool/main/g/grub2/grub2_1.99~rc1-13/changelog grub2 (1.99~20110106-1) experimental; urgency=low * New Bazaar snapshot. - Check that named RAID array devices exist before using them (closes: #606035). - Clear terminfo output on initialisation (closes: #569678). - Fix grub-probe when btrfs is on / without a separate /boot. Sander -- Humilis IT Services and Solutions http://www.humilis.net -- 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
How to know whether disks handle flush requests correctly
The btrfs wiki Main Page warns that it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power on disks that don't handle flush requests correctly. How do you know if this applies to your drives? Is there a way to test it, or a model list, or are newer SATA drives (magnetic, not SSDs) always ok? Does it depend on the controller? (I have a SiI 3114, latest BIOS.) I would also be using btrfs on top of dm-crypt (with the latest release kernel). Some kernel versions ago, the message that write barriers aren't supported disappeared; can I assume the device mapper / dm-crypt is not a problem with regards to flushing? Paul -- 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: Cannot Deinstall a Debian Package
On Thursday 5 May, 2011 23:33:33 Sander wrote: Can you do: echo true /var/lib/dpkg/info/grub-installer.postinst and try again? At some point somehow grup-pc apparently got installed, even with the script failure. So I tried my dist-upgrade again, and seems to have completed almost 400 packages, but three still fail: Errors were encountered while processing: linux-image-2.6.38-2-amd64 grub-pc linux-image-2.6-amd64 E: Sub-process /usr/bin/dpkg returned an error code (1) I can't reboot at this point, as on this machine I started a 'balance' through ssh on another machine, and it's been running for over 12 hours. It does not respond to ^C and I'm afraid to reboot with it running. -- 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: Cannot Deinstall a Debian Package
cac...@quantum-sci.com wrote (ao): On Thursday 5 May, 2011 23:33:33 Sander wrote: Can you do: echo true /var/lib/dpkg/info/grub-installer.postinst and try again? At some point somehow grup-pc apparently got installed, even with the script failure. So I tried my dist-upgrade again, and seems to have completed almost 400 packages, but three still fail: Errors were encountered while processing: linux-image-2.6.38-2-amd64 grub-pc linux-image-2.6-amd64 E: Sub-process /usr/bin/dpkg returned an error code (1) Can you post the error? Sander -- Humilis IT Services and Solutions http://www.humilis.net -- 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: [RFC PATCH] Btrfs: do not flush csum items of unchanged file data during treelog
On 05/05/2011 10:36 PM, liubo wrote:
The current code relogs the entire inode every time during fsync log,
and it is much better suited to small files rather than large ones.
During my performance test, the fsync performace of large files sucks,
and we can ascribe this to the tremendous amount of csum infos of the
large ones, cause we have to flush all of these csum infos into log trees
even when there are only _one_ change in the whole file data. Apparently,
to optimize fsync, we need to create a filter to skip the unnecessary csum
ones, that is, the corresponding file data remains unchanged before this fsync.
Here I have some test results to show, I use sysbench to do random write +
fsync.
===
sysbench --test=fileio --num-threads=1 --file-num=2 --file-block-size=4K
--file-total-size=8G --file-test-mode=rndwr --file-io-mode=sync
--file-extra-flags= [prepare, run]
===
Sysbench args:
- Number of threads: 1
- Extra file open flags: 0
- 2 files, 4Gb each
- Block size 4Kb
- Number of random requests for random IO: 1
- Read/Write ratio for combined random IO test: 1.50
- Periodic FSYNC enabled, calling fsync() each 100 requests.
- Calling fsync() at the end of test, Enabled.
- Using synchronous I/O mode
- Doing random write test
Sysbench results:
===
Operations performed: 0 Read, 1 Write, 200 Other = 10200 Total
Read 0b Written 39.062Mb Total transferred 39.062Mb
===
a) without patch: (*SPEED* : 451.01Kb/sec)
112.75 Requests/sec executed
b) with patch: (*SPEED* : 4.7533Mb/sec)
1216.84 Requests/sec executed
PS: I've made a _sub transid_ stuff patch, but it does not perform as
effectively as this patch,
and I'm wanderring where the problem is and trying to improve it more.
Signed-off-by: Liu Boliubo2...@cn.fujitsu.com
---
fs/btrfs/tree-log.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index c50271a..b934a36 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -2662,6 +2662,9 @@ static noinline int copy_items(struct btrfs_trans_handle
*trans,
extent = btrfs_item_ptr(src, start_slot + i,
struct btrfs_file_extent_item);
+ if (btrfs_file_extent_generation(src, extent)
trans-transid)
+ continue;
+
found_type = btrfs_file_extent_type(src, extent);
if (found_type == BTRFS_FILE_EXTENT_REG ||
found_type == BTRFS_FILE_EXTENT_PREALLOC) {
Seems reasonable to me,
Reviewed-by: Josef Bacik jo...@redhat.com
Thanks,
Josef
--
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: Cannot Deinstall a Debian Package
On Friday 6 May, 2011 05:20:28 Sander wrote: Can you post the error? # apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 3 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Do you want to continue [Y/n]? Setting up linux-image-2.6.38-2-amd64 (2.6.38-3) ... Running depmod. Running update-initramfs. update-initramfs: Generating /boot/initrd.img-2.6.38-2-amd64 initrd.img(/boot/initrd.img-2.6.38-2-amd64 ) points to /boot/initrd.img-2.6.38-2-amd64 (/boot/initrd.img-2.6.38-2-amd64) -- doing nothing at /var/lib/dpkg/info/linux-image-2.6.38-2-amd64.postinst line 348, STDIN line 7. vmlinuz(/boot/vmlinuz-2.6.38-2-amd64 ) points to /boot/vmlinuz-2.6.38-2-amd64 (/boot/vmlinuz-2.6.38-2-amd64) -- doing nothing at /var/lib/dpkg/info/linux-image-2.6.38-2-amd64.postinst line 348, STDIN line 7. Examining /etc/kernel/postinst.d. run-parts: executing /etc/kernel/postinst.d/dkms 2.6.38-2-amd64 /boot/vmlinuz-2.6.38-2-amd64 dkms: running auto installation service for kernel 2.6.38-2-amd64: vboxhost (3.2.12)...failed. run-parts: executing /etc/kernel/postinst.d/initramfs-tools 2.6.38-2-amd64 /boot/vmlinuz-2.6.38-2-amd64 run-parts: executing /etc/kernel/postinst.d/pm-utils 2.6.38-2-amd64 /boot/vmlinuz-2.6.38-2-amd64 run-parts: executing /etc/kernel/postinst.d/update-notifier 2.6.38-2-amd64 /boot/vmlinuz-2.6.38-2-amd64 run-parts: executing /etc/kernel/postinst.d/zz-update-grub 2.6.38-2-amd64 /boot/vmlinuz-2.6.38-2-amd64 /usr/sbin/grub-probe: error: cannot stat `/dev/root'. run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1 Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-2.6.38-2-amd64.postinst line 801, STDIN line 7. dpkg: error processing linux-image-2.6.38-2-amd64 (--configure): subprocess installed post-installation script returned error exit status 9 configured to not write apport reports Setting up grub-pc (1.99~rc1-13) ... grub-probe: error: cannot stat `/dev/root'. Installation finished. No error reported. /usr/sbin/grub-probe: error: cannot stat `/dev/root'. dpkg: error processing grub-pc (--configure): subprocess installed post-installation script returned error exit status 1 configured to not write apport reports dpkg: dependency problems prevent configuration of linux-image-2.6-amd64: linux-image-2.6-amd64 depends on linux-image-2.6.38-2-amd64; however: Package linux-image-2.6.38-2-amd64 is not configured yet. dpkg: error processing linux-image-2.6-amd64 (--configure): dependency problems - leaving unconfigured configured to not write apport reports Errors were encountered while processing: linux-image-2.6.38-2-amd64 grub-pc linux-image-2.6-amd64 E: Sub-process /usr/bin/dpkg returned an error code (1) -- 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: How to know whether disks handle flush requests correctly
On 05/06/2011 05:13 AM, Paul Schroeder wrote: The btrfs wiki Main Page warns that it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power on disks that don't handle flush requests correctly. How do you know if this applies to your drives? Is there a way to test it, or a model list, or are newer SATA drives (magnetic, not SSDs) always ok? Does it depend on the controller? (I have a SiI 3114, latest BIOS.) I would also be using btrfs on top of dm-crypt (with the latest release kernel). Some kernel versions ago, the message that write barriers aren't supported disappeared; can I assume the device mapper / dm-crypt is not a problem with regards to flushing? Yeah if you don't see those messages you can be fairly certain you are ok. Thanks, Josef -- 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: Cannot Deinstall a Debian Package
cac...@quantum-sci.com wrote (ao): On Friday 6 May, 2011 05:20:28 Sander wrote: Can you post the error? Do you want to continue [Y/n]? Setting up linux-image-2.6.38-2-amd64 (2.6.38-3) ... /usr/sbin/grub-probe: error: cannot stat `/dev/root'. run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1 Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-2.6.38-2-amd64.postinst line 801, STDIN line 7. dpkg: error processing linux-image-2.6.38-2-amd64 (--configure): subprocess installed post-installation script returned error exit status 9 configured to not write apport reports Setting up grub-pc (1.99~rc1-13) ... grub-probe: error: cannot stat `/dev/root'. Installation finished. No error reported. /usr/sbin/grub-probe: error: cannot stat `/dev/root'. Can you try: dpkg -i /var/cache/apt/archives/grub-pc_1.99~rc1-13_amd64.deb apt-get dist-upgrade If that (second step) doesn't work: echo true /var/lib/dpkg/info/grub-installer.postinst apt-get dist-upgrade grub-install /dev/sda update-grub Sander -- Humilis IT Services and Solutions http://www.humilis.net -- 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: Cannot Deinstall a Debian Package
Hallo, Cacook, Du meintest am 06.05.11: I can't reboot at this point, as on this machine I started a 'balance' through ssh on another machine, and it's been running for over 12 hours. It does not respond to ^C and I'm afraid to reboot with it running. That's a behaviour which was described in this mailing lists some weeks ago. You have certainly studied that thread? Balancing 4 TByte may need more than 1 day. Look every hour at the last lines of dmesg. Viele Gruesse! Helmut -- 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: How to know whether disks handle flush requests correctly
Excerpts from Josef Bacik's message of 2011-05-06 09:10:23 -0400: On 05/06/2011 05:13 AM, Paul Schroeder wrote: The btrfs wiki Main Page warns that it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power on disks that don't handle flush requests correctly. How do you know if this applies to your drives? Is there a way to test it, or a model list, or are newer SATA drives (magnetic, not SSDs) always ok? Does it depend on the controller? (I have a SiI 3114, latest BIOS.) I would also be using btrfs on top of dm-crypt (with the latest release kernel). Some kernel versions ago, the message that write barriers aren't supported disappeared; can I assume the device mapper / dm-crypt is not a problem with regards to flushing? Yeah if you don't see those messages you can be fairly certain you are ok. Thanks, The easiest way to tell for sure is to do two tests: dd if=/dev/zero of=/mnt/foo bs=4K count=1 dd if=/dev/zero of=/mnt/foo bs=4K count=1 oflag=sync Run this with the filesystem mounted normally and again with the filesystem mounted -o nobarrier. -o nobarrier should be dramatically and hugely faster, almost like we're not writing to the disk at all. -chris -- 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: Cannot Deinstall a Debian Package
Same old problem. On Friday 6 May, 2011 06:21:58 Sander wrote: Can you try: dpkg -i /var/cache/apt/archives/grub-pc_1.99~rc1-13_amd64.deb apt-get dist-upgrade # dpkg -i /var/cache/apt/archives/grub-pc_1.99~rc1-13_amd64.deb (Reading database ... 135273 files and directories currently installed.) Preparing to replace grub-pc 1.99~rc1-13 (using .../grub-pc_1.99~rc1-13_amd64.deb) ... Unpacking replacement grub-pc ... Setting up grub-pc (1.99~rc1-13) ... grub-probe: error: cannot stat `/dev/root'. Installation finished. No error reported. /usr/sbin/grub-probe: error: cannot stat `/dev/root'. dpkg: error processing grub-pc (--install): subprocess installed post-installation script returned error exit status 1 Processing triggers for man-db ... Errors were encountered while processing: grub-pc # If that (second step) doesn't work: echo true /var/lib/dpkg/info/grub-installer.postinst apt-get dist-upgrade # echo true /var/lib/dpkg/info/grub-installer.postinst # dpkg -i /var/cache/apt/archives/grub-pc_1.99~rc1-13_amd64.deb (Reading database ... 135273 files and directories currently installed.) Preparing to replace grub-pc 1.99~rc1-13 (using .../grub-pc_1.99~rc1-13_amd64.deb) ... Unpacking replacement grub-pc ... Setting up grub-pc (1.99~rc1-13) ... grub-probe: error: cannot stat `/dev/root'. Installation finished. No error reported. /usr/sbin/grub-probe: error: cannot stat `/dev/root'. dpkg: error processing grub-pc (--install): subprocess installed post-installation script returned error exit status 1 Processing triggers for man-db ... Errors were encountered while processing: grub-pc # which update-grub /usr/sbin/update-grub # /usr/sbin/update-grub -v grub-mkconfig (GRUB) 1.99~rc1-13 Apparently 1.99~rc1-13 is installed and synaptic confirms this, despite the script failure, although every .mod file in /usr/lib/grub is in the i386-pc directory. I'm running 64bit Debian Testing with kernel 2.6.37-2. -- 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: Cannot Deinstall a Debian Package
cac...@quantum-sci.com wrote (ao): # dpkg -i /var/cache/apt/archives/grub-pc_1.99~rc1-13_amd64.deb (Reading database ... 135273 files and directories currently installed.) Preparing to replace grub-pc 1.99~rc1-13 (using .../grub-pc_1.99~rc1-13_amd64.deb) ... Unpacking replacement grub-pc ... Setting up grub-pc (1.99~rc1-13) ... grub-probe: error: cannot stat `/dev/root'. Hm. Just do cp /bin/true /usr/sbin/grub-probe Sander -- Humilis IT Services and Solutions http://www.humilis.net -- 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: Cannot Deinstall a Debian Package
On Friday 6 May, 2011 07:17:00 you wrote: Hm. Just do cp /bin/true /usr/sbin/grub-probe Yikes, it came up with an ncurses screen saying: GRUB failed to install to the following devices: │ │ │ │ /dev/sda │ │ │ │ Do you want to continue anyway? If you do, your computer may not start up properly. │ │ │ │ Writing GRUB to boot device failed - continue? │ │ │ │Yes No │ │ Say No and another ncurses screen saying: The grub-pc package is being upgraded. This menu allows you to select which devices│ │ you'd like grub-install to be automatically run for, if any. │ │ │ │ Running grub-install automatically is recommended in most situations, to prevent the │ │ installed GRUB core image from getting out of sync with GRUB modules or grub.cfg. │ │ │ │ If you're unsure which drive is designated as boot drive by your BIOS, it is often a │ │ good idea to install GRUB to all of them. │ │ │ │ Note: it is possible to install GRUB to partition boot records as well, and some │ │ appropriate partitions are offered here. However, this forces GRUB to use the │ │ blocklist mechanism, which makes it less reliable, and therefore is not recommended. │ │ │ │ GRUB install devices: │ │ │ │[*] /dev/sda (750156 MB; WDC_WD7500BPKT-00PK4T0) │ │ │ │ │ │ Ok So I canceled out of it, not knowing WTH. I don't understand why the newer grub still doesn't understand BTRFS? # cp /bin/true /usr/sbin/grub-probe # dpkg -i /var/cache/apt/archives/grub-pc_1.99~rc1-13_amd64.deb (Reading database ... 135273 files and directories currently installed.) Preparing to replace grub-pc 1.99~rc1-13 (using .../grub-pc_1.99~rc1-13_amd64.deb) ... Unpacking replacement grub-pc ... Setting up grub-pc (1.99~rc1-13) ... Auto-detection of a filesystem of failed. Please report this together with the output of /usr/sbin/grub-probe --device-map=/boot/grub/device.map --target=fs -v /boot/grub to bug-g...@gnu.org ^[Auto-detection of a filesystem of failed. Please report this together with the output of /usr/sbin/grub-probe --device-map=/boot/grub/device.map --target=fs -v /boot/grub to bug-g...@gnu.org Auto-detection of a filesystem of failed. Please report this together with the output of /usr/sbin/grub-probe --device-map=/boot/grub/device.map --target=fs -v /boot/grub to bug-g...@gnu.org Generating grub.cfg ... Found background image: /usr/share/images/desktop-base/desktop-grub.png Found linux image: /boot/vmlinuz-2.6.38-2-amd64 Found initrd image: /boot/initrd.img-2.6.38-2-amd64 Found linux image: /boot/vmlinuz-2.6.37-2 Found Windows XP Pro on /dev/sda4 done Processing triggers for man-db ... #/usr/sbin/grub-probe --device-map=/boot/grub/device.map --target=fs -v /boot/grub # -- 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: [RFC PATCH] Btrfs: do not flush csum items of unchanged file data during treelog
Excerpts from liubo's message of 2011-05-05 22:36:09 -0400: The current code relogs the entire inode every time during fsync log, and it is much better suited to small files rather than large ones. During my performance test, the fsync performace of large files sucks, and we can ascribe this to the tremendous amount of csum infos of the large ones, cause we have to flush all of these csum infos into log trees even when there are only _one_ change in the whole file data. Apparently, to optimize fsync, we need to create a filter to skip the unnecessary csum ones, that is, the corresponding file data remains unchanged before this fsync. Here I have some test results to show, I use sysbench to do random write + fsync. === sysbench --test=fileio --num-threads=1 --file-num=2 --file-block-size=4K --file-total-size=8G --file-test-mode=rndwr --file-io-mode=sync --file-extra-flags= [prepare, run] === Sysbench args: - Number of threads: 1 - Extra file open flags: 0 - 2 files, 4Gb each - Block size 4Kb - Number of random requests for random IO: 1 - Read/Write ratio for combined random IO test: 1.50 - Periodic FSYNC enabled, calling fsync() each 100 requests. - Calling fsync() at the end of test, Enabled. - Using synchronous I/O mode - Doing random write test Sysbench results: === Operations performed: 0 Read, 1 Write, 200 Other = 10200 Total Read 0b Written 39.062Mb Total transferred 39.062Mb === a) without patch: (*SPEED* : 451.01Kb/sec) 112.75 Requests/sec executed b) with patch: (*SPEED* : 4.7533Mb/sec) 1216.84 Requests/sec executed PS: I've made a _sub transid_ stuff patch, but it does not perform as effectively as this patch, and I'm wanderring where the problem is and trying to improve it more. Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com --- fs/btrfs/tree-log.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c index c50271a..b934a36 100644 --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -2662,6 +2662,9 @@ static noinline int copy_items(struct btrfs_trans_handle *trans, extent = btrfs_item_ptr(src, start_slot + i, struct btrfs_file_extent_item); +if (btrfs_file_extent_generation(src, extent) trans-transid) +continue; + Some rough math shows you get 368 requests/sec per line added by this patch. Just think about how much better the metric would be without the whitespace! Really though, nicely done. You're still copying the extent items into the log tree even though they are from older transactions. If you push the check into btrfs_log_inode, you can avoid even more work. -chris -- 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: Cannot Deinstall a Debian Package
On Friday 6 May, 2011 07:58:47 you wrote: Say 'yes', try to finish your upgrade. Now when I ran it, it went as normal for some reason. Then: grub-install /dev/sda Auto-detection of a filesystem of failed. Please report this together with the output of /usr/sbin/grub-probe --device-map=/boot/grub/device.map --target=fs -v /boot/grub to bug-g...@gnu.org update-grub Generating grub.cfg ... Found background image: /usr/share/images/desktop-base/desktop-grub.png Found linux image: /boot/vmlinuz-2.6.38-2-amd64 Found initrd image: /boot/initrd.img-2.6.38-2-amd64 Found linux image: /boot/vmlinuz-2.6.37-2 Found Windows XP Pro on /dev/sda4 done I'm afraid to reboot though, because yesterday I started a btrfs fi balance on this machine while sshed to another, and that is still running 15 hours later with no indication of progress nor sign of abating. ^C is ineffective. -- 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: Cannot Deinstall a Debian Package
On Friday 6 May, 2011 08:15:25 cac...@quantum-sci.com wrote: I'm afraid to reboot though, because yesterday I started a btrfs fi balance on this machine while sshed to another, and that is still running 15 hours later with no indication of progress nor sign of abating. ^C is ineffective. Wow. I was very nearly completely screwed. I went ahead and rebooted, but grub.cfg was not set up at all. I had no way to run update-grub on that root, and so tried manually filling in the missing parameters. That didn't work, probably through the obfuscation of UUIDs I couldn't determine what was really going on. What a terrible idea the way they were implemented, UUIDs. Why not put the current device assignment somewhere in the number? Terrible. I ended up copying an old grub.cfg from a backup, and that got me at least booted, though with lots of grub errors. Now I am at a loss. I don't understand this. grub-update at least -pretended- to work before I rebooted. I am still in shock. MUST get some actual work done today, rather than bit-twiddling. MUST try and make a living. -- 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: Cannot Deinstall a Debian Package
Anyone here? On Friday 6 May, 2011 10:09:29 cac...@quantum-sci.com wrote: On Friday 6 May, 2011 08:15:25 cac...@quantum-sci.com wrote: I'm afraid to reboot though, because yesterday I started a btrfs fi balance on this machine while sshed to another, and that is still running 15 hours later with no indication of progress nor sign of abating. ^C is ineffective. Wow. I was very nearly completely screwed. I went ahead and rebooted, but grub.cfg was not set up at all. I had no way to run update-grub on that root, and so tried manually filling in the missing parameters. That didn't work, probably through the obfuscation of UUIDs I couldn't determine what was really going on. What a terrible idea the way they were implemented, UUIDs. Why not put the current device assignment somewhere in the number? Terrible. I ended up copying an old grub.cfg from a backup, and that got me at least booted, though with lots of grub errors. Now I am at a loss. I don't understand this. grub-update at least -pretended- to work before I rebooted. I am still in shock. MUST get some actual work done today, rather than bit-twiddling. MUST try and make a living. -- 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
Re: Cannot Deinstall a Debian Package
On Fri, May 06, 2011 at 01:04:28PM -0700, cac...@quantum-sci.com wrote: Anyone here? Could you create link from you root parition to /dev/root and try again? -- Tomasz Torcz Morality must always be based on practicality. xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen -- 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: Cannot Deinstall a Debian Package
cac...@quantum-sci.com wrote (ao): Wow. I was very nearly completely screwed. I went ahead and rebooted, but grub.cfg was not set up at all. I had no way to run update-grub on that root, and so tried manually filling in the missing parameters. That didn't work, probably through the obfuscation of UUIDs I couldn't determine what was really going on. What a terrible idea the way they were implemented, UUIDs. Why not put the current device assignment somewhere in the number? Terrible. That would kinda defeat the purpose :p I ended up copying an old grub.cfg from a backup, and that got me at least booted, though with lots of grub errors. Now I am at a loss. What errors .. I don't understand this. grub-update at least -pretended- to work before I rebooted. I am still in shock. MUST get some actual work done today, rather than bit-twiddling. MUST try and make a living. Dude, really .. Sander -- Humilis IT Services and Solutions http://www.humilis.net -- 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: Cannot Deinstall a Debian Package
cac...@quantum-sci.com wrote: I don't understand this. Clearly. Please continue the discussion in a debian or grub forum.. It really has nothing to do with btrfs. //Peter -- 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: Cannot Deinstall a Debian Package
On Friday 6 May, 2011 13:51:37 Peter Stuge wrote: cac...@quantum-sci.com wrote: I don't understand this. Clearly. Please continue the discussion in a debian or grub forum.. It really has nothing to do with btrfs. No thanks. This is a BTRFS problem, and if you people don't want to face it, that's fine. I'm tearing out BTRFS and using another filesystem. And rest assured, I'm warning others too. That's enough. -- 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: Cannot Deinstall a Debian Package
cac...@quantum-sci.com wrote: # update-grub /usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?). # update-grub -v grub-mkconfig (GRUB) 1.99~rc1-13 # It's still BTRFS incompatibility. Either that, or maybe something has broken in your many attempts to solve the problem while avoiding to educate yourself. I don't understand this. grub-update at least -pretended- to work before I rebooted. I am still in shock. MUST get some actual work done today, rather than bit-twiddling. MUST try and make a living. Dude, really .. Really, what? You -really- have no idea of the pressures I'm under. I'm afraid that's something you should have considered before choosing to mkfs.btrfs. Don't want to help, don't. I -really- don't have much more time to fool with this. I'm sorry that you decided to use experimental software without being prepared for the consequences. But it does sound like you've actually had ample warning. Stop fooling with this. You'll likely not be successful if you are only interested in the quick fix, and people helping you with this will basically be wasting their time since you seem very unlikely to contribute anything back. (Like high quality debugging, a testing environment, or even patches. All of which take both time and significant technical skill to produce.) //Peter -- 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: Cannot Deinstall a Debian Package
cac...@quantum-sci.com wrote: Clearly. Please continue the discussion in a debian or grub forum.. It really has nothing to do with btrfs. No thanks. This is a BTRFS problem, and if you people don't want to face it, that's fine. A problem that happens when you use btrfs is not neccessarily a btrfs problem. Do I agree that it sucks that distributions make assumptions about filesystems? Yes certainly! Is that a problem for btrfs, and others? Yes. Is it a problem *in* btrfs? Not the least. It's also not something that can be dealt with in this forum, where the topic is the code that implements btrfs. I'm tearing out BTRFS and using another filesystem. In your situation this seems like an excellent choice. And rest assured, I'm warning others too. That would be great! Warn others that btrfs is still experimental. Please also warn people to make backups, even if they are not using btrfs. And remember to warn people that the debian+grub combination seems to make assumptions about filesystems. You will do everyone a great service! //Peter -- 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: Cannot Deinstall a Debian Package
On Fri, May 06, 2011 at 02:20:48PM -0700, cac...@quantum-sci.com wrote: I'm tearing out BTRFS and using another filesystem. I think this is probably a good conclusion for you. I would strongly suggest you pick something reliable (like ext3 or ext4) for your future needs. Picking an experimental filesystem for your primary usage on a mission-critical system is an idiosyncratic choice, to say the least. I would also suggest keeping regular and tested backups, because if you can't cope with losing all your data for the time it takes to recreate it all, you _will_ need your backups at some point. And rest assured, I'm warning others too. I'm sorry you feel the need to do this. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- I hate housework. You make the beds, you wash the dishes, and --- six months later you have to start all over again. signature.asc Description: Digital signature
Re: Cannot Deinstall a Debian Package
Hugo Mills wrote: On Fri, May 06, 2011 at 02:20:48PM -0700, cac...@quantum-sci.com wrote: I'm tearing out BTRFS and using another filesystem. I think this is probably a good conclusion for you. I would strongly suggest you pick something reliable (like ext3 or ext4) for your future needs. Picking an experimental filesystem for your primary usage on a mission-critical system is an idiosyncratic choice, to say the least. I would also suggest keeping regular and tested backups, because if you can't cope with losing all your data for the time it takes to recreate it all, you _will_ need your backups at some point. And rest assured, I'm warning others too. I'm sorry you feel the need to do this. Hugo. I would like to take a moment to complement the members of the list for their professionalism, courtesy, politeness, and their efforts to help. I was reminded of an article in the Boston Globe that, while completely off any btrfs topic and pointed to here without any agenda whatsoever, for some might be an interesting read: How facts backfire Researchers discover a surprising threat to democracy: our brains July 11, 2010|Joe Keohane http://articles.boston.com/2010-07-11/bostonglobe/29324096_1_facts-misinformation-beliefs -dgb -- 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: Cannot Deinstall a Debian Package
On May 6, 2011 4:20 PM, cac...@quantum-sci.com wrote: On Friday 6 May, 2011 13:51:37 Peter Stuge wrote: cac...@quantum-sci.com wrote: I don't understand this. Clearly. Please continue the discussion in a debian or grub forum.. It really has nothing to do with btrfs. No thanks. This is a BTRFS problem, and if you people don't want to face it, that's fine. I'm tearing out BTRFS and using another filesystem. And rest assured, I'm warning others too. That's enough. hm. well to anyone who stumbles across this thread in the future, i've managed to use btrfs as my root on 1-3+ machines since circa 2.6.32, possibly even earlier (albeit not on Debian -- Archlinux w00tw00t ;-) ... ... there have certainly been a few bumps along the way, but not _once_ at the fault of btrfs ... not ONCE. tbh, I personally KNOW the developers and community here are doing one hell of a job -- i've been on this list almost 3 years i think, and along the way everyone has been most helpful + accommodating; i mean i've seen Chris and others extending rather gracious support levels when helping users recover data or debug issues ... and considering the demand/anticipation surrounding btrfs, this list is relatively devoid of support issues -- it's easily one of the highest quality groups i frequent. in short, distro's only just recently began offering btrfs at install time, with a big *warning sticker* on it. as others have already stated, this is clearly a Debian-specific problem, and does not reflect negatively on btrfs whatsoever, which has been nothing short of spectacular since the day i tried it and very much exactly as advertised -- i haven't used anything else since (save my servers ...). i am sorry you've found yourself in this position, i really am, as i've been there myself, but please do try and acknowledge the considerations already extended your way -- my post marks the 51st message in this thread. C Anthony -- 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: Cannot Deinstall a Debian Package
On Fri, May 6, 2011 at 8:51 PM, C Anthony Risinger anth...@extof.me wrote: On May 6, 2011 4:20 PM, cac...@quantum-sci.com wrote: On Friday 6 May, 2011 13:51:37 Peter Stuge wrote: cac...@quantum-sci.com wrote: I don't understand this. Clearly. Please continue the discussion in a debian or grub forum.. It really has nothing to do with btrfs. No thanks. This is a BTRFS problem, and if you people don't want to face it, that's fine. I'm tearing out BTRFS and using another filesystem. And rest assured, I'm warning others too. That's enough. i am sorry you've found yourself in this position, i really am, as i've been there myself, but please do try and acknowledge the considerations already extended your way -- my post marks the 51st message in this thread. i see now that you're running a .32 kernel ... a bit after the fact, but i really wouldn't recommend using anything that old for something that's in such active development; IIRC, there were many feature gaps at that point (ENOSPC being the big one), and unless Debian is doing something special, .32 was when btrfs was declared ready for early adopters ... ie. stable was still way out on the horizon, no one even knew what she might look like yet :-) C Anthony -- 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
