Bug#934736: initramfs-tools: MODULES=dep fails when rootfs is zfs
Package: initramfs-tools Version: 0.130 Severity: normal Tags: patch Hi, In hook-funtions, dep_add_modules_mount() wants a real mount point while zfs only presents its mount point as a virtual one named by the underlying dataset in /proc/mounts, this makes the function abort claiming unable to detect the root device. Such behavior breaks the installation of kdump-tools with zfs as rootfs because it explictly generates a new initrd with MODULES=dep. Attached patch makes dep_add_modules_mount() return upon detecting a zfs rootfs. Because users who run zfs as rootfs are required to install zfs-initramfs package, where a lot more details are handled, there is no potential breakage for not handling zfs related kernel modules here. If someday we have built-in support of zfs in initramfs-tools package, this peice of code should be revisted, though. Regards, Aron 0001-hook-funtions-return-from-dep_add_modules_mount-for-.patch Description: Binary data
Bug#761275:
Bump on loongson 2e/2f removal issues. glibc is now built with mips32/mips64 ISAs, making loongson 2e/2f dead effectively. Thanks, Aron
Re: Out-of-tree kernel module udeb
On Sun, May 17, 2015 at 9:39 PM, Cyril Brulebois k...@debian.org wrote: Ben Hutchings b...@decadent.org.uk (2015-05-17): On Sun, 2015-05-17 at 13:25 +0200, Cyril Brulebois wrote: My personal stance on kernel related things would be upstream first. If it ain't going to be merged into mainline, or at least accepted as a patchset (like e.g. aufs3 or rt in wheezy) for src:linux, I'm not sure we want to support that. Cc-ing debian-kernel@ to see what they think. I strongly oppose adding OOT modules this way as a supposed workaround for licence incompatibility. Just to clarify: I didn't mean to suggest doing so to work around any license issues. I was just trying to mention an alternate way for stuff that aren't (going to be) in mainline and that might still land in Debian kernels. Build the module in the same source tree of Linux kernel (including patch at build time) is not a feasible option for ZoL because of the potential of licensing incompatibility, that is to say we are risk to combine CDDL work into GPL one. The only safe option is to build the module from another source package and eliminate the possibility of building that module into a monolithic kernel binary. Thanks, Aron -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAMr=8w4h0mv85ao-rxsaznrozdg9zhgpq-3kajss5d3w377...@mail.gmail.com
Re: [Pkg-zfsonlinux-devel] Kernel image and OOT auto builder environment (Was: Using out of tree modules in d-i)?
On Sat, May 25, 2013 at 3:08 AM, Turbo Fredriksson tu...@bayour.com wrote: On May 24, 2013, at 8:54 PM, Aron Xu wrote: What I can think of is to do the trick in d-i, since it already has the ability to retrieve and load udeb on the fly, and even prompt users for missing firmware. Maybe even build them using dkms? I saw that you can make d-i build all packages... So adding a extra hook or something that sees that this is a OOT module, then get it's dkms package, build (to a .deb/.udeb which I have patches sent upstream for) it and use that... It could be possible, but I don't think building it is acceptable, because it means you must pull in everything of build-essential to the d-i image, which is useless for most other people when they run d-i. Ah, ok then I think I know what you mean. I thought you meant when the d-i image is built... But how does this help keeping 'the current kernel' and the OOT's up-to-date? From what I think I understand of you proposal, the user. Which means we can't offer 'whatever-support-the-OOT-provides' globally in our install images. It would be up to the user to make sure that this is available. I was kind'a hoping we could do this as an organization and provide this for our users, instead of putting it to them to make it available for themselves. Now I understand what you mean, just use DKMS to build OOT modules at image generation time? Seems to be a good idea. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w6v=4b1+azgn2a4zub9znfsxmg30ntxdrlbaceucou...@mail.gmail.com
Re: [Pkg-zfsonlinux-devel] Kernel image and OOT auto builder environment (Was: Using out of tree modules in d-i)?
On Fri, May 24, 2013 at 11:53 PM, Turbo Fredriksson tu...@bayour.com wrote: On May 22, 2013, at 3:52 PM, Ben Hutchings wrote: Quoting from the report of our 2009 meeting, 20091015123106.ga16...@kyllikki.org: out of tree modules --- After a somewhat involved discussion taking into account the FTP masters extreme irritation about trying to match binaries to source by hand for the lenny release it was resolved to remove linux-modules-extra and -nonfree as they are an impossible to support approach. The Built-Using header should cover FTP masters' concerns. However it is still the case that omnibus source packages are unsustainable as many OOT modules are not kept up to date with the kernel API. I haven't been keeping up with the inner workings of Debian GNU/Linux the last couple of years, so please take this as-is. Is it possible to setup an automatic build system for kernel and modules? I know that we have (had?) an auto builder to build everything automatically (think it was mostly (?) used for the ports), but I was thinking about a special build system here. Very possibly just a modification of what we already have... That is, a special place to upload the kernel source to, and once the auto builder have successfully built a linux-image* package(s), then it will look in a special list for source packages to build as well. And once all those have succeeded to, THEN it will upload the kernel (and the OOT modules) to the ftp archive... To clarify: the kernel maintainer does not build and upload the package to the archives, but only uploads the source package to this special build system and it will do the rest... That way OOT modules should be able to keep up with the kernel releases and uploads without much (hopefully) extra work. And the added benefit is that once a new kernel version is available in the archives, the OOT modules will as well, without any extra lagg... This should be reasonably easy to do, and I volunteer to do the initial setup and/or prof-of-consept for all the versions we currently support (oldstable, stable and unstable). Having something like this may (or may not) generally help, but I'm not sure this is what we want to solve the problem. If OOT modules are added into d-i images directly, then we must set up something like this proposal to make sure the modules are available whenever a new kernel ABI is uploaded, and help d-i people to handle the brokenness if a change in kernel makes the OOT module does not build, or even function badly. This is hard to do, and I think there could be easier way for this specific issue. What I can think of is to do the trick in d-i, since it already has the ability to retrieve and load udeb on the fly, and even prompt users for missing firmware. Such functionality may be reused so that related udebs can be fetched and loaded when selected, and if all effort failed just generate an error message. By doing this a small check is performed to make sure the d-i kernel and the OOT modules are matched, so that d-i may get the ability to include OOT modules in the image, and the worst case is wasting several megabytes in the resulting images. debian-cd may also be improved to check OOT modules included in the image has correct version info to work together with the target d-i kernel to avoid such a waste. Finally, OOT modules may be listed in a separate list so that users are aware what they are doing, and d-i team can coordinate with maintainers of modules they want to include whenever an official image is generated (e.g. release CDs). As for how the small check would be implemented, the question can be discussed later in more detail if we agree that it's the preferred way to go with. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w7TsXC9tOYkws48sV0r+mv=mfzlb8l6z_3-xrqexfy...@mail.gmail.com
Re: [Pkg-zfsonlinux-devel] Kernel image and OOT auto builder environment (Was: Using out of tree modules in d-i)?
On Sat, May 25, 2013 at 2:45 AM, Turbo Fredriksson tu...@bayour.com wrote: On May 24, 2013, at 7:04 PM, Aron Xu wrote: and help d-i people to handle the brokenness if a change in kernel makes the OOT module does not build This should only happen when a new major version of the kernel comes out, which means it should only happen in unstable.. And we could make it so that it is possible to make that particular OOT skipped (manually or automatically after a specified time), and hence won't be available for that run of d-i. But within a oldstable or stable kernel, only the Debian version changes, right, so... But if a kernel changes a lot and often in unstable, support for that specific OOT will be intermittent. Might not be a huge problem in unstable. Unwanted, but not a huge deal... What I can think of is to do the trick in d-i, since it already has the ability to retrieve and load udeb on the fly, and even prompt users for missing firmware. Maybe even build them using dkms? I saw that you can make d-i build all packages... So adding a extra hook or something that sees that this is a OOT module, then get it's dkms package, build (to a .deb/.udeb which I have patches sent upstream for) it and use that... It could be possible, but I don't think building it is acceptable, because it means you must pull in everything of build-essential to the d-i image, which is useless for most other people when they run d-i. But either way would mean that the d-i builder have to do the fixing, instead of a group of people (should be the responsibility of the OOT module maintainer(s)). Such functionality may be reused so that related udebs can be fetched and loaded when selected, and if all effort failed just generate an error message. What if an OOT is a network module? Might be needed before the network is up to fetch it... This is what I've said that d-i can ask users for firmware, and the case is usually network drivers: http://wiki.debian.org/Firmware And if it's included in the monolithic image, then it will be up to the d-i builder/uploader to make sure that the module is available, not a group of people... -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w7burLHc=0rStLTDSrge=se67jghvpajmu3rh_-p3q...@mail.gmail.com
Bug#691977: please add be2iscsi module to d-i image
On Wed, Nov 7, 2012 at 12:03 PM, Ben Hutchings b...@decadent.org.uk wrote: On Thu, 2012-11-01 at 08:20 +0100, Christian PERRIER wrote: reassign 691977 linux thanks Quoting Aron Xu (happyaron...@gmail.com): Package: debian-installer Dear d-i maintainers, I found that be2iscsi module is absent in d-i image. The module are the driver of iSCSI functions in Emulex be2/3 NICs, which is a standard configuration for HP BL490c G7 blade servers. Missing this module makes d-i not able to detect the hard drive provided by the iSCSI HBA in the Emulex NIC, hence not able to install the system to SAN, which is vital for diskless configurations. Thanks for the suggestion. This indeed belongs to kernel packages as the linux source package is the one building d-i kernels and modules set. I'm not familiar with NICs that do iSCSI offload. Does the host need to provide any configuration to them, or is that all handled by the on-board firmware? Theoretically the new device should appear as something like a disk in host OS (looks like something in /dev/mapper/, but I'm not familiar with the kernel), at least on RHEL (also VMWare ESXi) and SuSE it works in such a way. While it may not work out of box on Debian because in my test Ubuntu 12.10 server iso has be2iscsi driver and the driver can be loaded automatically, but no additional disk-like device appear in partman. HP BL490/495 are almost targeted for virtualization, and it's very common to have only a small SD card within, or even completely diskless. I can do test for this issue to make it work on Debian, we have spare machine for testing. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w7_bpejixlf7tqjhf7ebjeckqpxi_rumk7-0p46mgj...@mail.gmail.com
Bug#689159: Please add 8021q vlan kernel support for d-i
Package: src:linux Hi, Installing on hardware that are directly connected to a VLAN trunk port is something that haven't been achieved by us (#433568), and now I'm working with my partner to get it finally landed. We are working on necessary patches for netcfg, and another important thing to fix is that d-i kernel does not support 8021q vlan, that is to say the module isn't included, nor available as udeb. I guess it's a good idea to provide such a udeb, don't you think so? -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w6wcxdwdamutmob6as2xqkm+jmhiuruok32nbdrpzc...@mail.gmail.com
Bug#516785: Bug #516785: linux-image-2.6.26-1-sparc64-smp: [sparc] SunFire480R cassini network driver kernel panic
On Fri, Jun 1, 2012 at 11:05 PM, Hermann Lauer hermann.la...@iwr.uni-heidelberg.de wrote: Aron, do you have a Sun Fire 480R ? If yes, I'm interested in getting a running binary kernel from you to rule out configuration and compiler issues. I have remote ssh access (root) to that running SunFire 408R, what can I do to help you? Note I need to keep the service running so don't expect me to try out something new... PS: I've disabled the rename function of udev and set hwaddress in /etc/network/interfaces directly to work around the always changing mac address. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w5x9-h70ihh_v7nr1ukhcnr2t7twchuwgg_3vbufiy...@mail.gmail.com
Bug#516785: Bug #516785: linux-image-2.6.26-1-sparc64-smp: [sparc] SunFire480R cassini network driver kernel panic
Here is some more information of our machine FYI. Attached dmesg_20120322T184612.txt is the dmesg generated during boot of the machine on Mar 22, 2012, which is the date we did our last reboot and put it into production. The machine has 14GB RAM, that is 512MB*(16+12). Because there is one broken RAM, we have to remove all the group of four to make the machine boot, so there is 2GB's loss. The network is dual-stacked IPv4 and IPv6. Both of the NICs have configured multiple IPv6 addresses, only one of them have one IPv4 address. But I confirm it does not have any problem with no connection or have only one NIC configured. The operating system when installed is 6.0.4, user space programs are updated to 6.0.5 later, but the kernel isn't updated. The kernel is linux-image-2.6.32-5-sparc64-smp, version 2.6.32-41squeeze2. I can confirm that 2.6.32-41 worked because its the default of 6.0.4 CD1. d-i prompted for firmware during installation, and I supplied all the firmware.tar.gz as well as an unpacked directory by a USB flash disk. Then the installation continued. The disk is configured as software RAID1 (hardware RAID card seems not being recognized), though /boot as a separated partition isn't configured in the RAID due to a glitch in d-i. /boot is ext3, and / is ext4. The Sun remote control card is installed but not configured. The server's load is normally not very high, but it's usually to have a load average of 2 ~ 3. Most of the loads are processing network requests with very few disk I/O. $ cat /proc/cpuinfo cpu : TI UltraSparc III+ (Cheetah+) fpu : UltraSparc III+ integrated FPU pmu : ultra3+ prom: OBP 4.13.0 2004/01/19 18:26 type: sun4u ncpus probed: 4 ncpus active: 4 D$ parity tl1 : 0 I$ parity tl1 : 0 Cpu0ClkTck : 47868c00 Cpu1ClkTck : 47868c00 Cpu2ClkTck : 47868c00 Cpu3ClkTck : 47868c00 MMU Type: Cheetah+ State: CPU0: online CPU1: online CPU2: online CPU3: online $ lspci :00:03.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] :00:06.0 IDE interface: Silicon Image, Inc. PCI0646 (rev 07) 0001:00:01.0 Fibre Channel: QLogic Corp. ISP2422-based 4Gb Fibre Channel to PCI-X HBA (rev 02) 0002:00:01.0 Bridge: Oracle Corporation RIO EBUS (rev 01) 0002:00:01.3 USB Controller: Oracle Corporation RIO USB (rev 01) 0002:00:02.0 Ethernet controller: Oracle Corporation Cassini 10/100/1000 (rev 20) 0003:00:01.0 Ethernet controller: Oracle Corporation Cassini 10/100/1000 (rev 20) 0003:00:02.0 SCSI storage controller: QLogic Corp. QLA2200 64-bit Fibre Channel Adapter (rev 05) -- Regards, Aron Xu [0.00] PROMLIB: Sun IEEE Boot Prom 'OBP 4.13.0 2004/01/19 18:26' [0.00] PROMLIB: Root node compatible: [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.32-5-sparc64-smp (Debian 2.6.32-41squeeze2) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Thu Mar 22 18:46:12 UTC 2012 [0.00] bootconsole [earlyprom0] enabled [0.00] ARCH: SUN4U [0.00] Ethernet address: 00:03:ba:8c:1f:11 [0.00] Kernel: Using 2 locked TLB entries for main kernel image. [0.00] Remapping the kernel... done. [0.00] OF stdout device is: /pci@8,70/SUNW,XVR-100@3 [0.00] PROM: Built device tree with 119498 bytes of memory. [0.00] Top of RAM: 0xb17fa6e000, Total RAM: 0x37fa5c000 [0.00] Memory hole size: 712704MB [0.00] [01014000-f8a00040] page_structs=131072 node=0 entry=1280/0 [0.00] [01014000-f8a00080] page_structs=131072 node=0 entry=1281/0 [0.00] [01014080-f8a000c0] page_structs=131072 node=0 entry=1282/0 [0.00] [01014080-f8a00100] page_structs=131072 node=0 entry=1283/0 [0.00] [01014100-f8a00140] page_structs=131072 node=0 entry=1284/0 [0.00] [01014100-f8a00180] page_structs=131072 node=0 entry=1285/0 [0.00] [01014180-f8a001c0] page_structs=131072 node=0 entry=1286/0 [0.00] [01014180-f8a00200] page_structs=131072 node=0 entry=1287/0 [0.00] [01014200-f8a00240] page_structs=131072 node=0 entry=1288/0 [0.00] [01014200-f8a00280] page_structs=131072 node=0 entry=1289/0 [0.00] [01014280-f8a002c0] page_structs=131072 node=0 entry=1290/0 [0.00] [01014280-f8a00300] page_structs=131072 node=0 entry=1291/0 [0.00] [01014300-f8a00340] page_structs=131072 node=0 entry=1292/0 [0.00] [01014300-f8a00380] page_structs=131072 node=0 entry=1293/0 [0.00] [01014380-f8a003c0] page_structs=131072 node=0 entry
Bug#516785: Bug #516785: linux-image-2.6.26-1-sparc64-smp: [sparc] SunFire480R cassini network driver kernel panic
Hi Hermann, Is it possible to describe the detailed physical status of all the two CPU/Memory boards? I would like to know which Slots do you place your CPUs and which memory module groups are installed (and how much) on both of the CPU/Memory boards. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w6pk87onm-pue_acdmufgkx8mmkc+na51wij7ndtxu...@mail.gmail.com
Bug#516785: [sparc] SunFire480R cassini network driver kernel panic
On Fri, Mar 30, 2012 at 12:57, Jonathan Nieder jrnie...@gmail.com wrote: Aron Xu wrote: It's a bit hard for me now because the machine is in production now. That's fine. Do I understand correctly then that no, you did not reproduce the cassini crash with an older kernel but only reproduced the lack of a crash with a newer one? I did not reproduce the cassini crash, just confirmed it does not crash on Squeeze. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w7guwuoldeyxqgkm3b_hqouq_y5ryg90zu-mylqw6w...@mail.gmail.com
Bug#665933: [SPARC] NIC mac address changed on reboot (driver: cassini)
Package: linux-image-2.6.32-5-sparc64-smp Version: 2.6.32-41squeeze2 Every time the system reboots, the NIC's MAC address gets changed, then udev changed the name of the interface. When network is configured in /etc/network/interface manually, it fails to get network connection. I'm not sure if it's a problem in the driver, or anything else. Currently I've applied following workaround: 1.Make udev don't rename the interface even MAC address has changed. # chmod -x write_net_rules # rm /etc/udev/rules.d/70-persistent-net.rules 2.Manually configure a hwaddress in /etc/network/interfaces for every interface available. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w55kqf6ssc6utway8s_tjziudtkqktlqgw_ridq0qm...@mail.gmail.com
Bug#516785: Bug #516785: linux-image-2.6.26-1-sparc64-smp: [sparc] SunFire480R cassini network driver kernel panic
Hi, I can confirm that Debian Squeeze 6.0.4, with kernel linux-image-2.6.32-5-sparc64-smp, version 2.6.32-41 or 2.6.32-41squeeze2, does not crash anymore. The installation process is smooth (d-i prompts for a firmware), and the system is working well. But don't run lshw with this kernel, it may cause panic (#665932). -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w4ppugepxKAMKVi_DGmDuX1j1E8A=cbd1egr7feaiu...@mail.gmail.com
Bug#665933: Bug #665933: [SPARC] NIC mac address changed on reboot (driver: cassini)
$ lsmod Module Size Used by xt_multiport2931 2 nf_conntrack_ipv4 10993 14 nf_defrag_ipv4 1139 1 nf_conntrack_ipv4 xt_connlimit3159 1 xt_state1335 13 nf_conntrack 53681 3 nf_conntrack_ipv4,xt_connlimit,xt_state xt_tcpudp 2503 13 xt_limit1974 2 iptable_filter 2258 1 ip_tables 14835 1 iptable_filter x_tables 14314 6 xt_multiport,xt_connlimit,xt_state,xt_tcpudp,xt_limit,ip_tables ext3 126505 1 jbd38213 1 ext3 loop 11239 0 evdev 8088 0 ext4 326393 1 mbcache 5435 2 ext3,ext4 jbd2 67843 1 ext4 crc16 1295 1 ext4 raid1 18815 1 md_mod 83136 2 raid1 sd_mod 31796 5 crc_t10dif 1292 1 sd_mod usbhid 37592 0 hid74489 1 usbhid sg 26189 0 sr_mod 14098 0 cdrom 33735 1 sr_mod ata_generic 3399 0 ohci_hcd 18886 0 pata_cmd64x 5838 0 ehci_hcd 35029 0 qla2xxx 224070 3 libata147407 2 ata_generic,pata_cmd64x usbcore 118702 4 usbhid,ohci_hcd,ehci_hcd scsi_transport_fc 37580 1 qla2xxx cassini42652 0 scsi_tgt8202 1 scsi_transport_fc nls_base6817 1 usbcore scsi_mod 137229 7 sd_mod,sg,sr_mod,qla2xxx,libata,scsi_transport_fc,scsi_tgt ide_pci_generic 2972 0 -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w4kqr1f+4m7lywds54vdjdsuuzkgqvonpusx0kpe64...@mail.gmail.com
Bug#665933: [SPARC] NIC mac address changed on reboot (driver: cassini)
On Tue, Mar 27, 2012 at 22:24, Ben Hutchings b...@decadent.org.uk wrote: On Tue, 2012-03-27 at 15:31 +0800, Aron Xu wrote: Package: linux-image-2.6.32-5-sparc64-smp Version: 2.6.32-41squeeze2 [...] Can you also test Linux 3.2 from testing/unstable/backports? The system is in production status, it's hard to test a much newer kernel... -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w4yjwzbu5cxah7_vprt-mkqwl1uxnmnn28kdzeff2f...@mail.gmail.com
Bug#665932: [SPARC] kernel panic after executing lshw as root
On Tue, Mar 27, 2012 at 22:25, Ben Hutchings b...@decadent.org.uk wrote: On Tue, 2012-03-27 at 15:14 +0800, Aron Xu wrote: Package: linux-image-2.6.32-5-sparc64-smp Version: 2.6.32-41,2.6.32-41squeeze2 [...] Please also test this on Linux 3.2. The system is in production status, it's hard to test a much newer kernel... -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w5yp6za3vu--0a5bg64gf7hhkq0lgfa8uttdgj_oh0...@mail.gmail.com
Bug#608532: linux-2.6: very low I/O performance when vm's virtual disk placed on btrfs partition
Package: linux-2.6 Version: 2.6.32-29 While I was running a qemu-kvm virtual machine, I placed the virtual disk on one of my btrfs partition and it results in very low I/O performance. Comparing with an Ext3/4 host partition, it slows several times. The test I ran was installing Squeeze using d-i beta2 netinst ISO image, using expert installation mode: 1. The one using btrfs got nearly stopped at approximately 33% (it's the time to start installing base system, i.e. installing apt/aptitude). It takes about 1 hour to go forward to 50%, with my hard disk making a lot of noise, and finally I shut down the virtual machine. 2. The other one using ext4, which I tried to compare the performance, can finish the installation in ~45 minutes. The two partition are exactly the same hard disk, actually I formatted the previous btrfs partition to ext4 when I ran the test. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimtbzm2omnoali=jjkrvmxwtj6mbezb6dfby...@mail.gmail.com
Bug#608185: btrfs-tools: balance tree action should be only triggered by root
On Wed, Dec 29, 2010 at 22:49, Ben Hutchings b...@decadent.org.uk wrote: On Tue, 2010-12-28 at 21:53 +0800, Aron Xu wrote: Balance tree action of btrfs command should be limited to only root user, because it may cause data corrupt Why would it cause corruption? It shouldn't cause corruption if it always works as expected. But any disk maintenance action may cause problem regarding the stored data if there is something unexpected (software bug, known issues at specific situation, etc), especially at the point btrfs is still under heavy development. A common software failure might be bearable in some ways, but as for a filesystem it isn't. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinsz43-6w+8xc8oxh7qkxd81rmk+_z6m=s_y...@mail.gmail.com
Bug#608185: Bug #608185: btrfs-tools: balance tree action should be only triggered by root
2010/12/29 Uwe Kleine-König u.kleine-koe...@pengutronix.de: Hello Aron, On Wed, Dec 29, 2010 at 01:31:41PM +0800, Aron Xu wrote: I think a workaround (geteuid test) is needed to be settled in btrfs-tools, but not just wait for a kernel change. if you want to stop people doing bad things by accident, OK, but a geteuid test won't stop people that want to do harm on purpose. So the kernel solution is the only sensible IMHO. Best regards Uwe Yes, I know only kernel change will solve the problem so that we can stop people doing bad things deliberately. As you have said, we can prevent people doing it by accident by adding a geteuid test in btrfs-tools. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinyj85gbtvrsupj2jazhhwzpgodkjtsjmtyf...@mail.gmail.com
Bug#608185: Bug #608185: btrfs-tools: balance tree action should be only triggered by root
I think a workaround (geteuid test) is needed to be settled in btrfs-tools, but not just wait for a kernel change. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinlla_nf7n45qm0kohj==d4ax0way9w+j09j...@mail.gmail.com
