Re: 3.14.4 Kernel BUG at fs/namei.c : KDE's kate + ecryptfs + BTRFS + LVM2 + LUKS
On 05/16/2014 06:36 PM, Swâmi Petaramesh wrote: > Underlying is ecryptfs over BTRFS over LVM2 over LUKS (what else ?) I recently switched one of my drives to BTRFS because I wanted transparent compression. Since I also needed encryption, I chose: BTRFS => LUKS (Device Mapper) => SCSI Block. Is there any value having LVM2 and ecryptfs in the way you have stacked ? Just curious. -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
3.14.4 Kernel BUG at fs/namei.c : KDE's kate + ecryptfs + BTRFS + LVM2 + LUKS
(I'm not subscribed to linux-kernel, pls copy me on the anwsers) Hi there, # uname -a Linux zafu 3.14.4-1-ARCH #1 SMP PREEMPT Tue May 13 16:41:39 CEST 2014 x86_64 GNU/Linux I've seen the same thing happen several times in the last couple of months (so with said kernel version + at least 3.13) Symptom: KDE's kate freezes while saving a small (arbitrary) text file. (Yes, always KDE's kate and only KDE's kate, while saving a quite small text file... Besides this, machine's stability is rock-solid.) Afterwards the machine remains more or less able to access its filesystems, however KDE's Dolphin file manager is usually dead as well. Underlying is ecryptfs over BTRFS over LVM2 over LUKS (what else ?) System logs : kernel: [ cut here ] kernel: kernel BUG at fs/namei.c:2404! kernel: invalid opcode: [#1] PREEMPT SMP kernel: Modules linked in: nls_iso8859_1 usb_storage ctr ccm md5 fuse ecb ecryptfs encrypted_keys sha1_ssse3 sha1_generic hmac trusted nls_utf8 nls_cp437 vfat fat uvcvideo kernel: vboxdrv(O) sha256_ssse3 sha256_generic cbc dm_crypt dm_mod btrfs xor raid6_pq hid_multitouch hid_generic hid_logitech_dj usbhid hid sd_mod crc_t10dif atkbd libps2 kernel: CPU: 0 PID: 2142 Comm: kate Tainted: G O 3.14.4-1-ARCH #1 kernel: Hardware name: ASUSTeK COMPUTER INC. X202EV/X202EV, BIOS X202EV.200 02/27/2013 kernel: task: 8800a503bae0 ti: 880012dba000 task.ti: 880012dba000 kernel: RIP: 0010:[] [] may_delete+0x138/0x150 kernel: RSP: 0018:880012dbbd78 EFLAGS: 00010283 kernel: RAX: 88006ae82cc0 RBX: 8800b0f23d80 RCX: 000d1616 kernel: RDX: RSI: 8800b0f23d80 RDI: 8800ba841568 kernel: RBP: 880012dbbd98 R08: 7077732d6574616b R09: 8800b0f23c00 kernel: R10: 8080808080808080 R11: fefefefefefefeff R12: 8800a3836918 kernel: R13: 8800561501b8 R14: 8800b0f23d80 R15: 8800ba841568 kernel: FS: 7fe1e2648780() GS:88011ee0() knlGS: kernel: CS: 0010 DS: ES: CR0: 80050033 kernel: CR2: 7f2875f7 CR3: 13ee5000 CR4: 001407f0 kernel: Stack: kernel: 8800b0f23d80 8800ba841568 8800561501b8 8800b0f23d80 kernel: 880012dbbdd8 811ca6db 8800b0f23d80 kernel: 88006ae82cc0 880012f0e000 88008cc52000 8800ba841568 kernel: Call Trace: kernel: [] vfs_unlink+0x2b/0x160 kernel: [] ecryptfs_do_unlink+0x65/0x120 [ecryptfs] kernel: [] ecryptfs_unlink+0x12/0x20 [ecryptfs] kernel: [] vfs_unlink+0xe6/0x160 kernel: [] do_unlinkat+0x299/0x300 kernel: [] ? fput+0xe/0x10 kernel: [] ? task_work_run+0xb4/0xe0 kernel: [] ? do_notify_resume+0x95/0xa0 kernel: [] SyS_unlink+0x16/0x20 kernel: [] system_call_fastpath+0x16/0x1b kernel: Code: 1f 41 5d 83 e0 f0 41 5e 5d c3 66 0f 1f 84 00 00 00 00 00 b8 ff ff ff ff eb b1 66 0f 1f 84 00 00 00 00 00 0f 0b 66 0f 1f 44 00 00 <0f> 0b 66 0f 1f 44 00 00 b8 kernel: RIP [] may_delete+0x138/0x150 kernel: RSP kernel: ---[ end trace 73914218811ba28d ]--- -- Swâmi Petaramesh http://petaramesh.org PGP 9076E32E -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
AIX LVM support : block/partitions, kpartx, dmraid or lvm2 or ...
Hello, I have recently written a read-only support for linux for AIX 3 & 4 lvm disks, and submitted a patch for the linux block/partitions subsystem, for which I have no feedback yet. Now I wonder, as AIX LVM can describe mirrored and splitted logical volumes, is block/partitions the right place for it ? It seems that only contiguous partitions can be described. Am I mistaken ? I looked also at kpartx, but it seems to me that kpartx has the same limitations as block/partitions. Should I rather make a patch for dmraid or lvm2 or some other tool I am not aware of ? What would be the best place for that support ? I have working code that can generate tables for dmsetup, and I know there is some demand for AIX LVM and AIX JFS support in linux, but where should I send it ? Thanks in advance Philippe PS: Of course, AIX LVM support does only make sense if AIX JFS file systems are supported. I have written read-only support for cwAIX JFSit also, and I plan to submit it when I have a solution for AIX LVM, so that the AIX JFS code can be tested by others. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange LVM2/DM data corruption with 2.6.11.12
* Alexander Nyberg ([EMAIL PROTECTED]) wrote: > Please upgrade to 2.6.12.6 (I don't remember exactly in which > 2.6.12.x it went in), it contains a bugfix that should fix what > you are seeing. 2.6.13 also has this. Yep, that was 2.6.12.4, and here's the patch: http://www.kernel.org/git/?p=linux/kernel/git/chrisw/stable-queue.git;a=blob_plain;h=6267a6b8da4b52eaf0fbddd9091a6e6ff2fe233c thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange LVM2/DM data corruption with 2.6.11.12
On Thu, Sep 08, 2005 at 11:58:54AM +0200 Ludovic Drolez wrote: > Hi ! > > We are developing (GPLed) disk cloning software similar to partimage: it's > an intelligent 'dd' which backups only used sectors. > > Recently I added LVM1/2 support to it, and sometimes we saw LVM > restorations failing randomly (Disk images are not corrupted, but the > result of the restoration can be lead to a corrupted filesystem). If a > restoration fails, just try another one and it will work... > Please upgrade to 2.6.12.6 (I don't remember exactly in which 2.6.12.x it went in), it contains a bugfix that should fix what you are seeing. 2.6.13 also has this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Strange LVM2/DM data corruption with 2.6.11.12
Hi ! We are developing (GPLed) disk cloning software similar to partimage: it's an intelligent 'dd' which backups only used sectors. Recently I added LVM1/2 support to it, and sometimes we saw LVM restorations failing randomly (Disk images are not corrupted, but the result of the restoration can be lead to a corrupted filesystem). If a restoration fails, just try another one and it will work... How the restoration program works: - I restore the LVM2 administrative data (384 sectors, most of the time), - I 'vgscan', 'vgchange', - open for writing the '/dev/dm-', - read a compressed file over NFS, - and put the sectors in place, so it's a succession of '_llseek()' and 'write()' to the DM device. But, *sometimes*, for example, the current seek position is at 9GB, and some data is written to sector 0 ! It happens randomly. Here is a typical strace of a restoration: write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512 write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512 _llseek(5, 20963328, [37604032512], SEEK_CUR) = 0 _llseek(5, 0, [37604032512], SEEK_CUR) = 0 _llseek(5, 2097152, [37606129664], SEEK_CUR) = 0 write(5, "\1\335E\0\f\0\1\2.\0\0\0\2\0\0\0\364\17\2\2..\0\0\0\0\0"..., 512) = 51 2 write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512 write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512 write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512 write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512 write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512 write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512 write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512 _llseek(5, 88076288, [37694210048], SEEK_CUR) = 0 _llseek(5, 0, [37694210048], SEEK_CUR) = 0 _llseek(5, 20971520, [37715181568], SEEK_CUR) = 0 write(5, "\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 512) = 5 12 As you can see, there are no seeks to sector 0, but something randomly write some data to sector 0 ! I could reproduce these random problems on different kind of PCs. But, the strace above comes from an improved version, which aggregates '_llseek's. A previous version, which did *many* 512 bytes seeks had much more problems. Aggregating seeks made the corruption to appears very rarely... And I more likely to happen, for a 40GB restoration than for a 10GB one. So less system calls to the DM/LVM2 layer seems to give less corruption probability. Any ideas ? Newer kernel releases could have fixed such a problem ? -- Ludovic DROLEZ Linbox / Free&ALter Soft http://lrs.linbox.org - Linbox Rescue Server GPL edition - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: File corruption on LVM2 on top of software RAID1
"Simon Matter" <[EMAIL PROTECTED]> wrote: > > While looking at some data corruption vulnerability reports on > Securityfocus I wonder why this issue does not get any attention from > distributors. I have an open bugzilla report with RedHat, have an open > customer service request with RedHat, have mailed peoples directly. No > real feedback. > I'm now in the process of restoring intergrity of my data with the help of > backups and mirrored data. Maybe I just care too much about other peoples > data, but I know that this bug will corrupt files on hundreds or thousands > of servers today and most people simply don't know it. Did I miss > something? I guess the bug hit really rarely and maybe the reports were lost in the permanent background noise of dodgy hardware. We only found and fixed it last week, due to much sleuthing by Matthew Stapleton. I assume vendor updates are in the pipeline. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: File corruption on LVM2 on top of software RAID1
> "Simon Matter" <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >> Please CC me as I'm not subscribed to the kernel list. >> >> I had a hard time identifying a serious problem in the 2.6 linux kernel. > > Yes, it is a serious problem. > >> It all started while evaluating RHEL4 for new servers. My data integrity >> tests gave me bad results - which I couldn't believe - and my first idea >> was - of course - bad hardware. I ordered new SCSI disks instead of the >> IDE disks, took another server, spent some money again, tried again and >> again. That's all long ago now... >> >> In my tests I get corrupt files on LVM2 which is on top of software >> raid1. >> (This is a common setup even mentioned in the software RAID HOWTO and >> has >> worked for me on RedHat 9 / kernel 2.4 for a long time now and it's my >> favourite configuration). Now, I tested two different distributions, >> three >> kernels, three different filesystems and three different hardware. I can >> always reproduce it with the following easy scripts: >> > > Thanks for doing that. > > There's one fix against 2.6.12.3 which is needed, but 2.6.9 didn't have > the > bug which this fix addresses. So unless 2.6.9 has a different problem, > this won't help. Sorry for the confusion, the 2.6.9 in question is a "RedHat Enterprise Kernel" which includes lots of backported patches and features. So it is no plain 2.6.9. The real problem is that most current distributions include this bug in one or the other way. They either have one of the affected versions in the kernel package or have an older kernel with the bug backported. What I know for sure is that the following distributions are affected: RedHat Enterprise 4 Fedora Core 4 SuSE 9.3 Debian with the latest "unstable" 2.6 kernel I couldn't verify Mandrake, Gentoo and others, but I expect them to be at risk too. While looking at some data corruption vulnerability reports on Securityfocus I wonder why this issue does not get any attention from distributors. I have an open bugzilla report with RedHat, have an open customer service request with RedHat, have mailed peoples directly. No real feedback. I'm now in the process of restoring intergrity of my data with the help of backups and mirrored data. Maybe I just care too much about other peoples data, but I know that this bug will corrupt files on hundreds or thousands of servers today and most people simply don't know it. Did I miss something? Simon > > But still, you should include this in testing please. > > > diff -puN fs/bio.c~bio_clone-fix fs/bio.c > --- devel/fs/bio.c~bio_clone-fix 2005-07-28 00:39:40.0 -0700 > +++ devel-akpm/fs/bio.c 2005-07-28 01:02:34.0 -0700 > @@ -261,6 +261,7 @@ inline void __bio_clone(struct bio *bio, >*/ > bio->bi_vcnt = bio_src->bi_vcnt; > bio->bi_size = bio_src->bi_size; > + bio->bi_idx = bio_src->bi_idx; > bio_phys_segments(q, bio); > bio_hw_segments(q, bio); > } > _ > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: File corruption on LVM2 on top of software RAID1
Andrew Morton <[EMAIL PROTECTED]> wrote: > > There's one fix against 2.6.12.3 which is needed, but 2.6.9 didn't have the > bug which this fix addresses. aargh, I see that it did fix it. Don't blame me. Blame people who screw up list threading by reading a mail->news gateway and hitting "reply". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: File corruption on LVM2 on top of software RAID1
"Simon Matter" <[EMAIL PROTECTED]> wrote: > > Hi, > > Please CC me as I'm not subscribed to the kernel list. > > I had a hard time identifying a serious problem in the 2.6 linux kernel. Yes, it is a serious problem. > It all started while evaluating RHEL4 for new servers. My data integrity > tests gave me bad results - which I couldn't believe - and my first idea > was - of course - bad hardware. I ordered new SCSI disks instead of the > IDE disks, took another server, spent some money again, tried again and > again. That's all long ago now... > > In my tests I get corrupt files on LVM2 which is on top of software raid1. > (This is a common setup even mentioned in the software RAID HOWTO and has > worked for me on RedHat 9 / kernel 2.4 for a long time now and it's my > favourite configuration). Now, I tested two different distributions, three > kernels, three different filesystems and three different hardware. I can > always reproduce it with the following easy scripts: > > LOGF=/root/diff.log > while true; do > rm -rf /home/XXX2 > rsync -a /home/XXX/ /home/XXX2 > date >> $LOGF > diff -r /home/XXX /home/XXX2 >> $LOGF > done > > the files in /home/XXX are ~15G of ISO images and rpms. > > diff.log looks like this: > Wed Aug 3 13:45:57 CEST 2005 > Binary files /home/XXX/ES3-U3/rhel-3-U3-i386-es-disc3.iso and > /home/XXX2/ES3-U3/rhel-3-U3-i386-es-disc3.iso differ > Wed Aug 3 14:09:14 CEST 2005 > Binary files /home/XXX/8.0/psyche-i386-disc1.iso and > /home/XXX2/8.0/psyche-i386-disc1.iso differ > Wed Aug 3 14:44:17 CEST 2005 > Binary files /home/XXX/7.3/valhalla-i386-disc3.iso and > /home/XXX2/7.3/valhalla-i386-disc3.iso differ > Wed Aug 3 15:15:05 CEST 2005 > Wed Aug 3 15:45:40 CEST 2005 > > > Tested software: > 1) RedHat EL4 > kernel-2.6.9-11.EL > vanilla 2.6.12.3 kernel > filesystems: EXT2, EXT3, XFS > > 2) NOVELL/SUSE 9.3 > kernel-default-2.6.11.4-21.7 > filesystem: EXT3 > > Tested Hardware: > 1) > - ASUS P2B-S board > - CPU PIII 450MHz > - Intel 440BX/ZX/DX Chipset > - 4x128M memory (ECC enabled) > - 2x IDE disks Seagate Barracuda 400G, connected to onboard "Intel PIIX4 > Ultra 33" > - Promise Ultra100TX2 adapter for additional tests > > 2) > - DELL PowerEdge 1400 > - CPU PIII 800MHz > - ServerWorks OSB4 Chipset > - 4x256M memory (ECC enabled) > - 2x U320 SCSI disks Maxtor Atlas 10K 146G > - onboard Adaptec aic7899 Ultra160 SCSI adapter > > 3) > - DELL PowerEdge 1850 > - CPU P4 XEON 2.8GHz > - 2G memory > - 2x U320 SCSI disks Maxtor Atlas 10K 73G SCA > - onboard LSI53C1030 SCSI adapter > > I've put some files toghether from the last test on the PE1850 server: > http://www.invoca.ch/bugs/linux-2.6-corruption-on-lvm2-on-raid1/ > > I've also filed a bug with RedHat: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164696 > > I have spent a lot of time on this bug because I consider it very serious. > I'm not a kernel hacker but if there is anything I can do to fix this, let > me know. > Thanks for doing that. There's one fix against 2.6.12.3 which is needed, but 2.6.9 didn't have the bug which this fix addresses. So unless 2.6.9 has a different problem, this won't help. But still, you should include this in testing please. diff -puN fs/bio.c~bio_clone-fix fs/bio.c --- devel/fs/bio.c~bio_clone-fix2005-07-28 00:39:40.0 -0700 +++ devel-akpm/fs/bio.c 2005-07-28 01:02:34.0 -0700 @@ -261,6 +261,7 @@ inline void __bio_clone(struct bio *bio, */ bio->bi_vcnt = bio_src->bi_vcnt; bio->bi_size = bio_src->bi_size; + bio->bi_idx = bio_src->bi_idx; bio_phys_segments(q, bio); bio_hw_segments(q, bio); } _ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: File corruption on LVM2 on top of software RAID1
> Once upon a time, "Simon Matter" <[EMAIL PROTECTED]> said: >>In my tests I get corrupt files on LVM2 which is on top of software >> raid1. >>(This is a common setup even mentioned in the software RAID HOWTO and has >>worked for me on RedHat 9 / kernel 2.4 for a long time now and it's my >>favourite configuration). Now, I tested two different distributions, >> three >>kernels, three different filesystems and three different hardware. I can >>always reproduce it with the following easy scripts: > > See: > > http://bugzilla.kernel.org/show_bug.cgi?id=4946 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152162 > > There's a one-line patch in there; see if that fixes the problem for > you. Hi Chris, Thank you for your help, indeed this oneliner fixes the corruption. I have tested with 2.6.12.3 + bio_clone fix and also built an updated RedHat EL4 kernel with the fix included. No corruption anymore. This fix should be applied to most kernels shipped with the latest Linux distributions. At least those products called Enterprise something should hurry in the interest of their customers. Do you think this will happen anytime soon? -- Simon Matter Invoca Systems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: File corruption on LVM2 on top of software RAID1
Once upon a time, "Simon Matter" <[EMAIL PROTECTED]> said: >In my tests I get corrupt files on LVM2 which is on top of software raid1. >(This is a common setup even mentioned in the software RAID HOWTO and has >worked for me on RedHat 9 / kernel 2.4 for a long time now and it's my >favourite configuration). Now, I tested two different distributions, three >kernels, three different filesystems and three different hardware. I can >always reproduce it with the following easy scripts: See: http://bugzilla.kernel.org/show_bug.cgi?id=4946 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152162 There's a one-line patch in there; see if that fixes the problem for you. -- Chris Adams <[EMAIL PROTECTED]> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
File corruption on LVM2 on top of software RAID1
Hi, Please CC me as I'm not subscribed to the kernel list. I had a hard time identifying a serious problem in the 2.6 linux kernel. It all started while evaluating RHEL4 for new servers. My data integrity tests gave me bad results - which I couldn't believe - and my first idea was - of course - bad hardware. I ordered new SCSI disks instead of the IDE disks, took another server, spent some money again, tried again and again. That's all long ago now... In my tests I get corrupt files on LVM2 which is on top of software raid1. (This is a common setup even mentioned in the software RAID HOWTO and has worked for me on RedHat 9 / kernel 2.4 for a long time now and it's my favourite configuration). Now, I tested two different distributions, three kernels, three different filesystems and three different hardware. I can always reproduce it with the following easy scripts: LOGF=/root/diff.log while true; do rm -rf /home/XXX2 rsync -a /home/XXX/ /home/XXX2 date >> $LOGF diff -r /home/XXX /home/XXX2 >> $LOGF done the files in /home/XXX are ~15G of ISO images and rpms. diff.log looks like this: Wed Aug 3 13:45:57 CEST 2005 Binary files /home/XXX/ES3-U3/rhel-3-U3-i386-es-disc3.iso and /home/XXX2/ES3-U3/rhel-3-U3-i386-es-disc3.iso differ Wed Aug 3 14:09:14 CEST 2005 Binary files /home/XXX/8.0/psyche-i386-disc1.iso and /home/XXX2/8.0/psyche-i386-disc1.iso differ Wed Aug 3 14:44:17 CEST 2005 Binary files /home/XXX/7.3/valhalla-i386-disc3.iso and /home/XXX2/7.3/valhalla-i386-disc3.iso differ Wed Aug 3 15:15:05 CEST 2005 Wed Aug 3 15:45:40 CEST 2005 Tested software: 1) RedHat EL4 kernel-2.6.9-11.EL vanilla 2.6.12.3 kernel filesystems: EXT2, EXT3, XFS 2) NOVELL/SUSE 9.3 kernel-default-2.6.11.4-21.7 filesystem: EXT3 Tested Hardware: 1) - ASUS P2B-S board - CPU PIII 450MHz - Intel 440BX/ZX/DX Chipset - 4x128M memory (ECC enabled) - 2x IDE disks Seagate Barracuda 400G, connected to onboard "Intel PIIX4 Ultra 33" - Promise Ultra100TX2 adapter for additional tests 2) - DELL PowerEdge 1400 - CPU PIII 800MHz - ServerWorks OSB4 Chipset - 4x256M memory (ECC enabled) - 2x U320 SCSI disks Maxtor Atlas 10K 146G - onboard Adaptec aic7899 Ultra160 SCSI adapter 3) - DELL PowerEdge 1850 - CPU P4 XEON 2.8GHz - 2G memory - 2x U320 SCSI disks Maxtor Atlas 10K 73G SCA - onboard LSI53C1030 SCSI adapter I've put some files toghether from the last test on the PE1850 server: http://www.invoca.ch/bugs/linux-2.6-corruption-on-lvm2-on-raid1/ I've also filed a bug with RedHat: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164696 I have spent a lot of time on this bug because I consider it very serious. I'm not a kernel hacker but if there is anything I can do to fix this, let me know. Simon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 016/198] oom-killer disable for iscsi/lvm2/multipath userland critical sections
From: Andrea Arcangeli <[EMAIL PROTECTED]>
iscsi/lvm2/multipath needs guaranteed protection from the oom-killer, so
make the magical value of -17 in /proc//oom_adj defeat the oom-killer
altogether.
(akpm: we still need to document oom_adj and friends in
Documentation/filesystems/proc.txt!)
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/fs/proc/base.c |2 +-
25-akpm/include/linux/mm.h |3 +++
25-akpm/mm/oom_kill.c |2 +-
3 files changed, 5 insertions(+), 2 deletions(-)
diff -puN
fs/proc/base.c~oom-killer-disable-for-iscsi-lvm2-multipath-userland-critical-sections
fs/proc/base.c
---
25/fs/proc/base.c~oom-killer-disable-for-iscsi-lvm2-multipath-userland-critical-sections
2005-04-12 03:21:07.242035944 -0700
+++ 25-akpm/fs/proc/base.c 2005-04-12 03:21:07.249034880 -0700
@@ -751,7 +751,7 @@ static ssize_t oom_adjust_write(struct f
if (copy_from_user(buffer, buf, count))
return -EFAULT;
oom_adjust = simple_strtol(buffer, &end, 0);
- if (oom_adjust < -16 || oom_adjust > 15)
+ if ((oom_adjust < -16 || oom_adjust > 15) && oom_adjust != OOM_DISABLE)
return -EINVAL;
if (*end == '\n')
end++;
diff -puN
include/linux/mm.h~oom-killer-disable-for-iscsi-lvm2-multipath-userland-critical-sections
include/linux/mm.h
---
25/include/linux/mm.h~oom-killer-disable-for-iscsi-lvm2-multipath-userland-critical-sections
2005-04-12 03:21:07.243035792 -0700
+++ 25-akpm/include/linux/mm.h 2005-04-12 03:21:07.250034728 -0700
@@ -857,5 +857,8 @@ int in_gate_area_no_task(unsigned long a
#define in_gate_area(task, addr) ({(void)task; in_gate_area_no_task(addr);})
#endif /* __HAVE_ARCH_GATE_AREA */
+/* /proc//oom_adj set to -17 protects from the oom-killer */
+#define OOM_DISABLE -17
+
#endif /* __KERNEL__ */
#endif /* _LINUX_MM_H */
diff -puN
mm/oom_kill.c~oom-killer-disable-for-iscsi-lvm2-multipath-userland-critical-sections
mm/oom_kill.c
---
25/mm/oom_kill.c~oom-killer-disable-for-iscsi-lvm2-multipath-userland-critical-sections
2005-04-12 03:21:07.245035488 -0700
+++ 25-akpm/mm/oom_kill.c 2005-04-12 03:21:07.251034576 -0700
@@ -145,7 +145,7 @@ static struct task_struct * select_bad_p
do_posix_clock_monotonic_gettime(&uptime);
do_each_thread(g, p)
/* skip the init task with pid == 1 */
- if (p->pid > 1) {
+ if (p->pid > 1 && p->oomkilladj != OOM_DISABLE) {
unsigned long points;
/*
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: oom-killer disable for iscsi/lvm2/multipath userland critical sections
Andrea,
I just successfully tested the patch on my environment. It actually
resolved OOM-killer problem for my iscsid.
Important note: daemon's parent must be init.
In my test, OOM-killer killed everything around but iscsid, and iscsid
successfully finished registration of new SCSI host in the middle of
crazy OOM-killer :)
Thanks!
Dima
On Sat, 2005-04-02 at 00:14 +0200, Andrea Arcangeli wrote:
> Hello,
>
> some private discussion (that was continuing some kernel-summit-discuss
> thread) ended in the below patch. I also liked a textual "disable"
> instead of value "-17" (internally to the kernel it could be represented
> the same way, but the /proc parsing would be more complicated). If you
> prefer textual "disable" we can change this of course.
>
> Comments welcome.
>
> From: Andrea Arcangeli <[EMAIL PROTECTED]>
> Subject: oom killer protection
>
> iscsi/lvm2/multipath needs guaranteed protection from the oom-killer.
>
> Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
>
> --- 2.6.12-seccomp/fs/proc/base.c.~1~ 2005-03-25 05:13:28.0 +0100
> +++ 2.6.12-seccomp/fs/proc/base.c 2005-04-01 23:47:22.0 +0200
> @@ -751,7 +751,7 @@ static ssize_t oom_adjust_write(struct f
> if (copy_from_user(buffer, buf, count))
> return -EFAULT;
> oom_adjust = simple_strtol(buffer, &end, 0);
> - if (oom_adjust < -16 || oom_adjust > 15)
> + if ((oom_adjust < -16 || oom_adjust > 15) && oom_adjust != OOM_DISABLE)
> return -EINVAL;
> if (*end == '\n')
> end++;
> --- 2.6.12-seccomp/include/linux/mm.h.~1~ 2005-03-25 05:13:28.0
> +0100
> +++ 2.6.12-seccomp/include/linux/mm.h 2005-04-01 23:53:11.0 +0200
> @@ -856,5 +856,8 @@ int in_gate_area_no_task(unsigned long a
> #define in_gate_area(task, addr) ({(void)task; in_gate_area_no_task(addr);})
> #endif /* __HAVE_ARCH_GATE_AREA */
>
> +/* /proc//oom_adj set to -17 protects from the oom-killer */
> +#define OOM_DISABLE -17
> +
> #endif /* __KERNEL__ */
> #endif /* _LINUX_MM_H */
> --- 2.6.12-seccomp/mm/oom_kill.c.~1~ 2005-03-08 01:02:30.0 +0100
> +++ 2.6.12-seccomp/mm/oom_kill.c 2005-04-01 23:46:18.0 +0200
> @@ -145,7 +145,7 @@ static struct task_struct * select_bad_p
> do_posix_clock_monotonic_gettime(&uptime);
> do_each_thread(g, p)
> /* skip the init task with pid == 1 */
> - if (p->pid > 1) {
> + if (p->pid > 1 && p->oomkilladj != OOM_DISABLE) {
> unsigned long points;
>
> /*
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
oom-killer disable for iscsi/lvm2/multipath userland critical sections
Hello,
some private discussion (that was continuing some kernel-summit-discuss
thread) ended in the below patch. I also liked a textual "disable"
instead of value "-17" (internally to the kernel it could be represented
the same way, but the /proc parsing would be more complicated). If you
prefer textual "disable" we can change this of course.
Comments welcome.
From: Andrea Arcangeli <[EMAIL PROTECTED]>
Subject: oom killer protection
iscsi/lvm2/multipath needs guaranteed protection from the oom-killer.
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
--- 2.6.12-seccomp/fs/proc/base.c.~1~ 2005-03-25 05:13:28.0 +0100
+++ 2.6.12-seccomp/fs/proc/base.c 2005-04-01 23:47:22.0 +0200
@@ -751,7 +751,7 @@ static ssize_t oom_adjust_write(struct f
if (copy_from_user(buffer, buf, count))
return -EFAULT;
oom_adjust = simple_strtol(buffer, &end, 0);
- if (oom_adjust < -16 || oom_adjust > 15)
+ if ((oom_adjust < -16 || oom_adjust > 15) && oom_adjust != OOM_DISABLE)
return -EINVAL;
if (*end == '\n')
end++;
--- 2.6.12-seccomp/include/linux/mm.h.~1~ 2005-03-25 05:13:28.0
+0100
+++ 2.6.12-seccomp/include/linux/mm.h 2005-04-01 23:53:11.0 +0200
@@ -856,5 +856,8 @@ int in_gate_area_no_task(unsigned long a
#define in_gate_area(task, addr) ({(void)task; in_gate_area_no_task(addr);})
#endif /* __HAVE_ARCH_GATE_AREA */
+/* /proc//oom_adj set to -17 protects from the oom-killer */
+#define OOM_DISABLE -17
+
#endif /* __KERNEL__ */
#endif /* _LINUX_MM_H */
--- 2.6.12-seccomp/mm/oom_kill.c.~1~2005-03-08 01:02:30.0 +0100
+++ 2.6.12-seccomp/mm/oom_kill.c2005-04-01 23:46:18.0 +0200
@@ -145,7 +145,7 @@ static struct task_struct * select_bad_p
do_posix_clock_monotonic_gettime(&uptime);
do_each_thread(g, p)
/* skip the init task with pid == 1 */
- if (p->pid > 1) {
+ if (p->pid > 1 && p->oomkilladj != OOM_DISABLE) {
unsigned long points;
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: md and RAID 5 [was Re: LVM2]
On Friday January 21, [EMAIL PROTECTED] wrote: > Thank you all for having been so kind in your responses and help. > > However, there is one more set of questions I have. > > Does the md (software raid) have disk size or raid volume limits? 2^31 sectors for individual disks. Arrays do not have this limit. > > If I am using such things as USB or 1394 disks, is there a way to use > labels in /etc/raidtab and with the tools so that when the disks, if > they do, get renumbered in /dev that all works fine. I am aware that the > kernel will autodetect these devices, but that the raidtab needs to be > consistent. This is what I am trying to figure out how to do. Scrap raidtools and /etc/raidtab. Explore "mdadm" and /etc/mdadm.conf NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM2
On Jan 20, 2005, at 16:40, Norbert van Nobelen wrote: RAID5 in software works pretty good (survived a failed disk, and recovered another failing raid in 1 month). Hardware is better since you don't have a boot partition left which is usually just present on one disk (you can mirror that yourself ofcourse). Err, you _can_ boot completely from a software RAID, it just takes a bit more work. I have an old PowerMac G4 400MHz with a Promise 20268 controller and 3 80GB drives booting from a software RAID. You just set up a 250-500MB boot partition mirrored with RAID 1 across all drives, then set up a RAID 5 swap partition and a RAID 5 LVM partition on each drive. Once LVM is configured with each remaining filesystem, install your distro (The new Debian-installer does very well) and set up Yaboot/GRUB/whatever to install a boot sector on each drive. Then set up a RAID+LVM initrd (Debian does this mostly automatically too), and reboot. This computer boots a custom 2.6.8.1 kernel, has 896MB RAM, and a 400MHz CPU, but it reads 41.5MiByte/sec from its RAID 5 partition with a 1MiByte blocksize, and has 16.8MiByte/sec over LVM over RAID 5 with the same blocksize. I've been following the discussions on 2.6 instability and "New development model" problems, but AFAICT, 2.6 has been rock stable on this box, which acts as an IPv4/IPv6 router/firewall/server. Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r !y?(-) --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: md and RAID 5 [was Re: LVM2]
Trever L. Adams wrote: > Thank you all for having been so kind in your responses and help. > > However, there is one more set of questions I have. > > Does the md (software raid) have disk size or raid volume limits? > > If I am using such things as USB or 1394 disks, is there a way to use > labels in /etc/raidtab and with the tools so that when the disks, if > they do, get renumbered in /dev that all works fine. I am aware that the > kernel will autodetect these devices, but that the raidtab needs to be > consistent. This is what I am trying to figure out how to do. EVMS can handle this for you. I've used it with a raid set I made with some of the drives being on usb and some on ide. If you use evms, you might want to consider the activation after all disks have been discovered. -- Lab tests show that use of micro$oft causes cancer in lab animals - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
md and RAID 5 [was Re: LVM2]
Thank you all for having been so kind in your responses and help. However, there is one more set of questions I have. Does the md (software raid) have disk size or raid volume limits? If I am using such things as USB or 1394 disks, is there a way to use labels in /etc/raidtab and with the tools so that when the disks, if they do, get renumbered in /dev that all works fine. I am aware that the kernel will autodetect these devices, but that the raidtab needs to be consistent. This is what I am trying to figure out how to do. Thank you, Trever Adams -- "A modest woman, dressed out in all her finery, is the most tremendous object in the whole creation." -- Goldsmith - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM2
With using RAID5 you can choose yourself howmany hot standby/failover disks you want to use. The number (or ratio) of disks used for failover of your raid will determine the chance that you have when one disk fails and complete failure of a raid. It is still pretty safe just to have 7 active disks and 1 hot standby disk, thus getting you 3500 Manufacturers GB (3.34TB) About LVM on a RAID: With hardware RAID it will work for sure. With software RAID: Make the RAID partitions and build your RAID. On that RAID, set the partition type to LVM And it should work On LVM you can then use ext3 (your preferred fs) On Thursday 20 January 2005 23:17, you wrote: > It is for a group. For the most part it is data access/retention. Writes > and such would be more similar to a desktop. I would use SATA if they > were (nearly) equally priced and there were awesome 1394 to SATA bridge > chips that worked well with Linux. So, right now, I am looking at ATA to > 1394. > > So, to get 2TB of RAID5 you have 6 500 GB disks right? So, will this > work within on LV? Or is it 2TB of diskspace total? So, are volume > groups pretty fault tolerant if you have a bunch of RAID5 LVs below > them? This is my one worry about this. > > Second, you mentioned file systems. We were talking about ext3. I have > never used any others in Linux (barring ext2, minixfs, and fat). I had > heard XFS from IBM was pretty good. I would rather not use reiserfs. > > Any recommendations. > > Trever > > P.S. Why won't an LV support over 2TB? > > S.P.S. I am not really worried about the boot and programs drive. They > will be spun down most of the time I am sure. > > On Thu, 2005-01-20 at 22:40 +0100, Norbert van Nobelen wrote: > > A logical volume in LVM will not handle more than 2TB. You can tie > > together the LVs in a volume group, thus going over the 2TB limit. Choose > > your filesystem well though, some have a 2TB limit too. > > > > Disk size: What are you doing with it. 500GB disks are ATA (maybe SATA). > > ATA is good for low end servers or near line storage, SATA can be used > > equally to SCSI (I am going to suffer for this remark). > > > > RAID5 in software works pretty good (survived a failed disk, and > > recovered another failing raid in 1 month). Hardware is better since you > > don't have a boot partition left which is usually just present on one > > disk (you can mirror that yourself ofcourse). > > > > Regards, > > > > Norbert van Nobelen > > > > On Thursday 20 January 2005 20:51, you wrote: > > > I recently saw Alan Cox say on this list that LVM won't handle more > > > than 2 terabytes. Is this LVM2 or LVM? What is the maximum amount of > > > disk space LVM2 (or any other RAID/MIRROR capable technology that is in > > > Linus's kernel) handle? I am talking with various people and we are > > > looking at Samba on Linux to do several different namespaces (obviously > > > one tree), most averaging about 3 terabytes, but one would have in > > > excess of 20 terabytes. We are looking at using 320 to 500 gigabyte > > > drives in these arrays. (How? IEEE-1394. Which brings a question I will > > > ask in a second email.) > > > > > > Is RAID 5 all that bad using this software method? Is RAID 5 available? > > > > > > Trever Adams > > > -- > > > "They that can give up essential liberty to obtain a little temporary > > > safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 > > > > > > - > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" > > > in the body of a message to [EMAIL PROTECTED] > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Please read the FAQ at http://www.tux.org/lkml/ > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" > > in the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > -- > "Assassination is the extreme form of censorship." -- George Bernard > Shaw (1856-1950) -- http://www.edusupport.nl";>EduSupport: Linux Desktop for schools and small to medium business in The Netherlands and Belgium - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM2
Even as LVM user, guess what I used before answering (-: On Thursday 20 January 2005 23:34, Alasdair G Kergon wrote: > On Thu, Jan 20, 2005 at 03:22:14PM -0700, Trever L. Adams wrote: > > PV = the device > > VG = groups of them (the RAID5 array?) > > LV = what? the file system? > > http://www.tldp.org/HOWTO/LVM-HOWTO/anatomy.html > http://www.novell.com/products/linuxenterpriseserver8/whitepapers/LVM.pdf > [Out-of-date now, but descriptions of concepts still useful.] > > LVM mailing list for LVM questions: > https://www.redhat.com/mailman/listinfo/linux-lvm > > Alasdair - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM2
Trever L. Adams wrote: It is for a group. For the most part it is data access/retention. Writes and such would be more similar to a desktop. I would use SATA if they were (nearly) equally priced and there were awesome 1394 to SATA bridge chips that worked well with Linux. So, right now, I am looking at ATA to 1394. So, to get 2TB of RAID5 you have 6 500 GB disks right? So, will this work within on LV? Or is it 2TB of diskspace total? So, are volume groups pretty fault tolerant if you have a bunch of RAID5 LVs below them? This is my one worry about this. Second, you mentioned file systems. We were talking about ext3. I have never used any others in Linux (barring ext2, minixfs, and fat). I had heard XFS from IBM was pretty good. I would rather not use reiserfs. Any recommendations. Trever They all forgot to mention one more limitation, the maximum filesystem size supported by the address_space structure in linux. If you are running on ia32, then you get stuck with 2^32 filesystem blocks, or 16 Tbytes in one filesystem because of the way an address space structure is used to cache the metadata. If you use an Athlon 64 that limitation goes away. Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM2
On Thu, Jan 20, 2005 at 03:22:14PM -0700, Trever L. Adams wrote: > PV = the device > VG = groups of them (the RAID5 array?) > LV = what? the file system? http://www.tldp.org/HOWTO/LVM-HOWTO/anatomy.html http://www.novell.com/products/linuxenterpriseserver8/whitepapers/LVM.pdf [Out-of-date now, but descriptions of concepts still useful.] LVM mailing list for LVM questions: https://www.redhat.com/mailman/listinfo/linux-lvm Alasdair -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM2
XFS is an SGI project. http://oss.sgi.com/ I've been using it for quite a while and am quite happy with it; it is very fast and very fault tolerant. The only warning I'd like to give about it is it seems that some Linux developers seem to have a bad taste in their mouth when it comes to XFS; go figure. -- jeffrey hundstad Trever L. Adams wrote: It is for a group. For the most part it is data access/retention. Writes and such would be more similar to a desktop. I would use SATA if they were (nearly) equally priced and there were awesome 1394 to SATA bridge chips that worked well with Linux. So, right now, I am looking at ATA to 1394. So, to get 2TB of RAID5 you have 6 500 GB disks right? So, will this work within on LV? Or is it 2TB of diskspace total? So, are volume groups pretty fault tolerant if you have a bunch of RAID5 LVs below them? This is my one worry about this. Second, you mentioned file systems. We were talking about ext3. I have never used any others in Linux (barring ext2, minixfs, and fat). I had heard XFS from IBM was pretty good. I would rather not use reiserfs. Any recommendations. Trever P.S. Why won't an LV support over 2TB? S.P.S. I am not really worried about the boot and programs drive. They will be spun down most of the time I am sure. On Thu, 2005-01-20 at 22:40 +0100, Norbert van Nobelen wrote: A logical volume in LVM will not handle more than 2TB. You can tie together the LVs in a volume group, thus going over the 2TB limit. Choose your filesystem well though, some have a 2TB limit too. Disk size: What are you doing with it. 500GB disks are ATA (maybe SATA). ATA is good for low end servers or near line storage, SATA can be used equally to SCSI (I am going to suffer for this remark). RAID5 in software works pretty good (survived a failed disk, and recovered another failing raid in 1 month). Hardware is better since you don't have a boot partition left which is usually just present on one disk (you can mirror that yourself ofcourse). Regards, Norbert van Nobelen On Thursday 20 January 2005 20:51, you wrote: I recently saw Alan Cox say on this list that LVM won't handle more than 2 terabytes. Is this LVM2 or LVM? What is the maximum amount of disk space LVM2 (or any other RAID/MIRROR capable technology that is in Linus's kernel) handle? I am talking with various people and we are looking at Samba on Linux to do several different namespaces (obviously one tree), most averaging about 3 terabytes, but one would have in excess of 20 terabytes. We are looking at using 320 to 500 gigabyte drives in these arrays. (How? IEEE-1394. Which brings a question I will ask in a second email.) Is RAID 5 all that bad using this software method? Is RAID 5 available? Trever Adams -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- "Assassination is the extreme form of censorship." -- George Bernard Shaw (1856-1950) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM2
On Thu, Jan 20, 2005 at 03:17:37PM -0700, Trever L. Adams wrote: > Second, you mentioned file systems. We were talking about ext3. I have > never used any others in Linux (barring ext2, minixfs, and fat). I had > heard XFS from IBM was pretty good. I would rather not use reiserfs. XFS is from SGI. JFS is from IBM. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM2
PV = the device VG = groups of them (the RAID5 array?) LV = what? the file system? So, from what you are telling me, and the man page, 2.6.x with LVM2 can have basically any size of PV, VG, and LV I want. Am I flawed in my understanding? Thank you, Trever On Thu, 2005-01-20 at 22:02 +, Alasdair G Kergon wrote: > On Thu, Jan 20, 2005 at 10:40:02PM +0100, Norbert van Nobelen wrote: > > A logical volume in LVM will not handle more than 2TB. You can tie together > > the LVs in a volume group, thus going over the 2TB limit. > > Confused over terminology? > Tie PVs together to form a VG, then divide VG up into LVs. > > Size limit depends on metadata format and the kernel: old LVM1 format has > lower size limits - see the vgcreate man page. > > New LVM2 metadata format relaxes those limits and lets you have LVs > 2TB > with a 2.6 kernel. > > Alasdair -- "Assassination is the extreme form of censorship." -- George Bernard Shaw (1856-1950) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM2
It is for a group. For the most part it is data access/retention. Writes and such would be more similar to a desktop. I would use SATA if they were (nearly) equally priced and there were awesome 1394 to SATA bridge chips that worked well with Linux. So, right now, I am looking at ATA to 1394. So, to get 2TB of RAID5 you have 6 500 GB disks right? So, will this work within on LV? Or is it 2TB of diskspace total? So, are volume groups pretty fault tolerant if you have a bunch of RAID5 LVs below them? This is my one worry about this. Second, you mentioned file systems. We were talking about ext3. I have never used any others in Linux (barring ext2, minixfs, and fat). I had heard XFS from IBM was pretty good. I would rather not use reiserfs. Any recommendations. Trever P.S. Why won't an LV support over 2TB? S.P.S. I am not really worried about the boot and programs drive. They will be spun down most of the time I am sure. On Thu, 2005-01-20 at 22:40 +0100, Norbert van Nobelen wrote: > A logical volume in LVM will not handle more than 2TB. You can tie together > the LVs in a volume group, thus going over the 2TB limit. Choose your > filesystem well though, some have a 2TB limit too. > > Disk size: What are you doing with it. 500GB disks are ATA (maybe SATA). ATA > is good for low end servers or near line storage, SATA can be used equally to > SCSI (I am going to suffer for this remark). > > RAID5 in software works pretty good (survived a failed disk, and recovered > another failing raid in 1 month). Hardware is better since you don't have a > boot partition left which is usually just present on one disk (you can mirror > that yourself ofcourse). > > Regards, > > Norbert van Nobelen > > On Thursday 20 January 2005 20:51, you wrote: > > I recently saw Alan Cox say on this list that LVM won't handle more than > > 2 terabytes. Is this LVM2 or LVM? What is the maximum amount of disk > > space LVM2 (or any other RAID/MIRROR capable technology that is in > > Linus's kernel) handle? I am talking with various people and we are > > looking at Samba on Linux to do several different namespaces (obviously > > one tree), most averaging about 3 terabytes, but one would have in > > excess of 20 terabytes. We are looking at using 320 to 500 gigabyte > > drives in these arrays. (How? IEEE-1394. Which brings a question I will > > ask in a second email.) > > > > Is RAID 5 all that bad using this software method? Is RAID 5 available? > > > > Trever Adams > > -- > > "They that can give up essential liberty to obtain a little temporary > > safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- "Assassination is the extreme form of censorship." -- George Bernard Shaw (1856-1950) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM2
On Thu, Jan 20, 2005 at 10:40:02PM +0100, Norbert van Nobelen wrote: > A logical volume in LVM will not handle more than 2TB. You can tie together > the LVs in a volume group, thus going over the 2TB limit. Confused over terminology? Tie PVs together to form a VG, then divide VG up into LVs. Size limit depends on metadata format and the kernel: old LVM1 format has lower size limits - see the vgcreate man page. New LVM2 metadata format relaxes those limits and lets you have LVs > 2TB with a 2.6 kernel. Alasdair -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM2
A logical volume in LVM will not handle more than 2TB. You can tie together the LVs in a volume group, thus going over the 2TB limit. Choose your filesystem well though, some have a 2TB limit too. Disk size: What are you doing with it. 500GB disks are ATA (maybe SATA). ATA is good for low end servers or near line storage, SATA can be used equally to SCSI (I am going to suffer for this remark). RAID5 in software works pretty good (survived a failed disk, and recovered another failing raid in 1 month). Hardware is better since you don't have a boot partition left which is usually just present on one disk (you can mirror that yourself ofcourse). Regards, Norbert van Nobelen On Thursday 20 January 2005 20:51, you wrote: > I recently saw Alan Cox say on this list that LVM won't handle more than > 2 terabytes. Is this LVM2 or LVM? What is the maximum amount of disk > space LVM2 (or any other RAID/MIRROR capable technology that is in > Linus's kernel) handle? I am talking with various people and we are > looking at Samba on Linux to do several different namespaces (obviously > one tree), most averaging about 3 terabytes, but one would have in > excess of 20 terabytes. We are looking at using 320 to 500 gigabyte > drives in these arrays. (How? IEEE-1394. Which brings a question I will > ask in a second email.) > > Is RAID 5 all that bad using this software method? Is RAID 5 available? > > Trever Adams > -- > "They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
LVM2
I recently saw Alan Cox say on this list that LVM won't handle more than 2 terabytes. Is this LVM2 or LVM? What is the maximum amount of disk space LVM2 (or any other RAID/MIRROR capable technology that is in Linus's kernel) handle? I am talking with various people and we are looking at Samba on Linux to do several different namespaces (obviously one tree), most averaging about 3 terabytes, but one would have in excess of 20 terabytes. We are looking at using 320 to 500 gigabyte drives in these arrays. (How? IEEE-1394. Which brings a question I will ask in a second email.) Is RAID 5 all that bad using this software method? Is RAID 5 available? Trever Adams -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
