Take Control Of Your Conference Calls

From owner-freebsd-fs Mon Dec 10 4:31:18 2001 Delivered-To: freebsd-fs@freebsd.org Received: from email01.aon.at (WARSL401PIP7.highway.telekom.at [195.3.96.115]) by hub.freebsd.org (Postfix) with SMTP id 2ACAA37B421 for ; Mon, 10 Dec 2001 04:30:21 -0800 (PST) Received: (qmail 657318 invoked from network); 10 Dec 2001 12:30:15 -0000 Received: from n054p029.adsl.highway.telekom.at (HELO mail.kpost.com) ([213.33.6.189]) (envelope-sender ) by qmail1.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 10 Dec 2001 12:30:15 -0000 From: "contractor@kpost.com" To: "5062@lycos.com" <5062@lycos.com> Message-ID: <1007991311.0499569422@mail.kpost.com> Subject: Reduce Travel Costs MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Dec 2001 04:30:21 -0800 (PST) Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Take Control Of Your Conference Calls

Long Distance Conferencing
Only 18 Cents Per Minute

Connects Up To 100 Participants=21

No setup fees
No contracts or monthly fees
Call anytime, from anywhere, to anywhere
International Dial In 18 cents per minute
Simplicity in set up and administration
Operator Help available 24/7

G= et the best quality, the easiest to use, and lowest rate in the industry.

If you like saving = money, fill out the form below and one of our consultants will contact you.

Required Input Field*

Name*

Web Address*

Company Name*

State*

Business Phone*

Home Phone

Email Address*

Type of Business

This ad is being sent in compliance with Senate Bill 1618= , Title 3, Section 301. You have recently visited our web site, referral or affiliate sit= es which indicated you were interested in communication services. If this email is reaching = you in error and you feel that you have not contacted us, Click here. We sincerely apologize, and assure you will be r= emoved from our distribution list.

To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Dec 11 9:32:20 2001 Delivered-To: freebsd-fs@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 075A937C180; Tue, 11 Dec 2001 09:30:33 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 585B914C57; Tue, 11 Dec 2001 18:30:31 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Stefan.Esser@o-tel-o.de Cc: freebsd-gnats-submit@FreeBSD.org, fs@freebsd.org Subject: Re: kern/32681: Reproducable PANIC in -stable References: <200112111500.fBBF04J48329@freefall.freebsd.org> From: Dag-Erling Smorgrav Date: 11 Dec 2001 18:30:30 +0100 In-Reply-To: <200112111500.fBBF04J48329@freefall.freebsd.org> Message-ID: Lines: 29 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Stefan.Esser@o-tel-o.de writes: > In order to check for the presence of some process %PID%, nessusd performs an > opendir("/proc/%PID%"), which can lead to a panic in fstafs(), if the > corresponding process just finishes just before the call to fstatfs ... Ah, OK, I see. First, if nessus needs to check for the existence of a process with a given PID, it should kill(pid, 0) instead of relying on procfs. Second, the problem seems to be insufficient locking - possibly in pseudofs, but equally possibly in the VFS system. When a process terminates, pseudofs automatically reclaims all vnodes associated with it, which leads to an obvious race condition which can only be avoided through proper locking. Looking at the pseudofs code, it doesn't seem to be at fault. When the process exits, pfs_exit() removes all vnodes associated with it from pseudofs' vnode cache, and vgone()s them. I'm starting to think that the race might be in namei(), actually - since the namei() call from fstatfs() succeeds, it means namei() found a vnode, but that vnode's v_mount is NULL, which means it's been reclaimed, which can't happen if it's referenced (can it?), and namei() is supposed to reference the vnode before it returns it. My bet is that there is a small race between namei() finding a vnode and referencing it, but I'm getting out of my depth. Does anybody else have any ideas? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Dec 11 14:16:45 2001 Delivered-To: freebsd-fs@freebsd.org Received: from acc0.visti.net (acc0.visti.net [195.64.225.233]) by hub.freebsd.org (Postfix) with ESMTP id 81A2537B41B for ; Tue, 11 Dec 2001 14:16:13 -0800 (PST) Received: from gw0.visti.net (gw0.visti.net [195.64.225.229]) by acc0.visti.net (8.8.8-Elvisti-980428/8.8.8) with ESMTP id AAA18775 for ; Wed, 12 Dec 2001 00:16:10 +0200 (EET) Received: from cscorp.com.ua (Ivanov-gw7r.visti.net [195.64.224.210] (may be forged)) by gw0.visti.net (8.12.1/8.12.1) with ESMTP id fBBLlx7u082230 for ; Wed, 12 Dec 2001 00:16:06 +0200 (EET)?g (envelope-from csc_seminar@cscorp.com.ua) Date: Wed, 12 Dec 2001 00:16:06 +0200 (EET) Message-Id: <200112112216.fBBLlx7u082230@gw0.visti.net> Received: from tanydura [192.168.101.101] by cscorp.com.ua [195.64.224.210] with SMTP (MDaemon.PRO.v5.0.4.R) for ; Tue, 11 Dec 2001 20:20:40 +0000 From: csc_seminar To: freebsd-fs@freebsd.org Subject: Invitation for seminar. Приглашение на семинар Reply-To: csc_seminar@cscorp.com.ua Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1251 X-MDRemoteIP: 192.168.101.101 X-Return-Path: csc_seminar@cscorp.com.ua X-MDaemon-Deliver-To: freebsd-fs@freebsd.org Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Представительство Компании Capital Standard Corporation приглашает Вас принять участие в однодневных консультационных семинарах-практикумах для эффективного и быстрого повышения квалификации сотрудников Вашей компании Однодневный консультационный семинар-практикум «Биржевая торговля на международных финансовых рынках. Практические аспекты» Дата проведения: 19 декабря 2001 года Время проведения семинара: 9.30-17.30 Место проведения: Институт международных отношений В программе семинара: 1. Спекуляции - как способ приумножения капитала: - Частные инвесторы - Корпоративные и другие участники рынка - Сумма, достаточная для работы 2. Инструменты мировых товарных и финансовых рынков: - FOREX - международный рынок обмена валют - Фьючерсные и опционные контракты 3. Технология и механизм биржевых и внебиржевых операций: - Законодательная база, правила и практика американской модели торговли - Валютный рынок «spot» - Биржевые торговые системы - Компьютерные торговые системы - Информационные системы и компьютерные технологии по обеспечению дилинговых операций 4. Как «дотянуться» до рынка: - Брокерская компания - Принципал (маркет-мейкер) - Торговый счёт - Маржа - Кредитное плечо - Совершение сделки - Плюсы и минусы "интернет-торговли" - Прибыльность операций 5. Прогнозирование рыночных тенденций: - Технический анализ - Фундаментальный анализ - Профессиональные компьютерные системы и программное обеспечение, используемое в работе дилеров Стоимость участия в семинаре: 440 гривен Для второго и третьего участника от одной компании скидка – 10%. В стоимость включены: обучение и консультации на семинаре, обед, кофе-брейки. Эксклюзивный альбом материалов «Биржевая торговля на международных финансовых рынках. Практические аспекты», подготовленного экспертами специально для участников с учётом всех последних изменений и дополнений. Однодневный консультационный семинар-практикум: «Таможенное регулирование внешнеэкономической деятельности» Дата проведения: 21 декабря 2001 года Время проведения семинара: 9.30-17.30 Место проведения: Конференц-зал гостиницы «Санкт-Петербург» В программе семинара: Особенности таможенного законодательства в сфере внешнеэкономической деятельности. Закон Украины «О Таможенном тарифе Украины» от 5.04.2001 № 2371-ІІІ. Изменения и дополнения в Закон Украины по состоянию на 1.12.01. Украинская товарная номенклатура внешнеэкономической деятельности. Особенности таможенного оформления в рамках соглашений о свободной торговле. Перспектива развития зоны свободной торговли. Новые правила страны происхождения товаров. Порядок применения сертификатов CT-1, EUR 1,2. Вопросы классификации товаров. Обзор нормативных документов ГТСУ по вопросам тарифного регулирования по состоянию на 1.12.01. Особенности заполнения ГТД при различных таможенных режимах. Лизинговые контракты, временный ввоз товара. Оформление ГТД по внешнеэкономическим договорам с участием более двух сторон. Критерии определения таможенными органами Украины «групп риска» (внешнеэкономические операции, которые требуют детальной проверки на законность сделки). Установление фактов таможенных правонарушений, классификация и процессуальное оформление фактов правонарушений, санкции, предусмотренные законодательством, последствия возможные для субъектов ВЭД. Правовые основы для осуществления международной административной помощи в таможенных зонах (участие Украины в международных конвенциях по таможенным вопросам, двух- и многосторонние межгосударственные договора). Порядок реализации конвенций, соглашений, о взаимной административной помощи в таможенных вопросах. Стоимость участия в семинаре 570 гривен Для второго и третьего участника от одной фирмы скидка – 10%. В стоимость включены: обучение и консультации на семинаре, обед, кофе-брейки. Эксклюзивный альбом материалов «Таможенное регулирование внешнеэкономической деятельности», подготовленного экспертами специально для участников с учётом всех последних изменений и дополнений Наша компания предлагает такую услугу как проведение индивидуальных консультационных семинаров по выбранной Вами тематике у Вас в офисе. Для участия в семинаре необходимо зарегистрироваться по нашим телефонам и подтвердить свое участие оплатой (044) 494 46 58, E-mail: csc_seminar@cscorp.com.ua Мы приносим свои извинения, если подобная рассылка Вам не интересна. Удалить свой адрес из списка подписчиков Вы можете, отослав письмо по адресу unsubscribe_sem@cscorp.com.ua To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Dec 11 19: 3:59 2001 Delivered-To: freebsd-fs@freebsd.org Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by hub.freebsd.org (Postfix) with ESMTP id B63CE37B416 for ; Tue, 11 Dec 2001 19:03:52 -0800 (PST) Received: from 66-44-4-121.s1137.apx1.lnh.md.dialup.rcn.com ([66.44.4.121] helo=localhost.) by smtp02.mrf.mail.rcn.net with smtp (Exim 3.33 #10) id 16DzgT-0001gJ-00; Tue, 11 Dec 2001 22:03:50 -0500 References: <200112111500.fBBF04J48329@freefall.freebsd.org> In-Reply-To: Date: Tue, 11 Dec 2001 21:52:15 EDT From: Eric Jacobs To: Dag-Erling Smorgrav , fs@freebsd.org Subject: Re: kern/32681: Reproducable PANIC in -stable Organization: X-Mailer: Post Office 0.7.2 build 20010211(by eric@localhost 2001/02/11 21:52:30) Message-ID: X-Mailer: PostOffice 0.7 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Dag-Erling Smorgrav wrote > Stefan.Esser@o-tel-o.de writes: > > > In order to check for the presence of some process %PID%, nessusd > > performs an opendir("/proc/%PID%"), which can lead to a panic in > > fstafs(), if the corresponding process just finishes just before the > > call to fstatfs ... > > Ah, OK, I see. First, if nessus needs to check for the existence of a > process with a given PID, it should kill(pid, 0) instead of relying on > procfs. Second, the problem seems to be insufficient locking - > possibly in pseudofs, but equally possibly in the VFS system. When a > process terminates, pseudofs automatically reclaims all vnodes > associated with it, which leads to an obvious race condition which can > only be avoided through proper locking. > > Looking at the pseudofs code, it doesn't seem to be at fault. When the > process exits, pfs_exit() removes all vnodes associated with it > from pseudofs' vnode cache, and vgone()s them. > > I'm starting to think that the race might be in namei(), actually - > since the namei() call from fstatfs() succeeds, it means namei() found a > vnode, but that vnode's v_mount is NULL, which means it's been > reclaimed, which can't happen if it's referenced (can it?), and namei() > is supposed to reference the vnode before it returns it. My bet is that > there is a small race between namei() finding a vnode and referencing > it, but I'm getting out of my depth. Does anybody else > have any ideas? I think you're on the wrong trail here. I don't run nessus, but I can reproduce a very similar crash with this little snippet: (on my FreeBSD 4.2 system) #include #include #include #include int main(void) { int p; int fd; char buf[50]; struct statfs sf; if (p = fork()) { sprintf(buf, "/proc/%d", p); fd = open(buf, O_RDONLY); printf("open successful fd=%d\n", fd); printf("1st fstatfs returns %d\n", fstatfs(fd, &sf)); sleep(1); printf("2nd fstatfs returns %d\n", fstatfs(fd, &sf)); } } This should crash before the third printf, so namei is not the culprit here. If this is the problem in the bug report, it stems from the following code in vfs_subr.c, in vgonel: /* * Delete from old mount point vnode list, if on one. */ if (vp->v_mount != NULL) insmntque(vp, (struct mount *)0); This ends up setting v_mount to 0, which happens to aggravate fstatfs as it is one of the very few syscalls that makes a VFS_* virtual call without checking the v_type of the vnode that is passed in. This problem could be solved one of several ways. One is of course to make a rule that says that that a vnode's v_type must be checked before a VFS call can be made. I'm not sure what functions other than fstatfs this would affect. Note that this would probably still have to affect other VFS syscalls that use namei rather than getvnode, such as statfs, as the vnode might go VBAD after the namei but before the virtual dispatch. There might have to be a way to hold the interlock from the v_type check until the dispatch to rule out the possibility of a race condition in between. Another possible solution could be modelled after the way that vgone handles the v_op field: /* * Delete from old mount point vnode list, if on one. */ if (vp->v_mount != NULL) insmntque(vp, dead_mount_p); In other words, all of the VBAD vnodes (vgoners) would be considered to be owned by a special mount structure which would always be valid, analogous to the dead_vnodeop_p structure for the VOP_* calls. This could avoid having to add explicit checks and/or interlocking scenarios for functions that want to call a VFS function given a vnode. -- P To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Dec 13 9:19:16 2001 Delivered-To: freebsd-fs@freebsd.org Received: from crotus.sc.intel.com (scfdns02.sc.intel.com [143.183.152.26]) by hub.freebsd.org (Postfix) with ESMTP id 21C5137B416; Thu, 13 Dec 2001 09:19:06 -0800 (PST) Received: from sedona.intel.com (sedona.ch.intel.com [143.182.218.21]) by crotus.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.48 2001/12/13 16:27:50 root Exp $) with ESMTP id RAA00736; Thu, 13 Dec 2001 17:19:05 GMT Received: from chlx169.ch.intel.com (chlx169.ch.intel.com [143.182.225.37]) by sedona.intel.com (8.9.1a/8.9.1/d: sendmail.cf,v 1.14 2001/01/02 18:39:59 steved Exp $) with ESMTP id KAA24128; Thu, 13 Dec 2001 10:19:05 -0700 (MST) X-Envelope-From: jreynold@sedona.ch.intel.com Received: (from jreynold@localhost) by chlx169.ch.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) id KAA16794; Thu, 13 Dec 2001 10:19:07 -0700 X-Authentication-Warning: chlx169.ch.intel.com: jreynold set sender to jreynold@sedona.ch.intel.com using -f From: John Reynolds~ MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15384.58121.214749.505032@chlx169.ch.intel.com> Date: Thu, 13 Dec 2001 10:19:05 -0700 To: questions@freebsd.org, fs@freebsd.org Subject: off_t governs the largest file size, correct? X-Mailer: VM 6.99 under Emacs 20.7.1 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all, I searched the mailing list archives looking for this information and all I found was a reference to a somewhat seemingly out-dated FAQ entry: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/install.html#AEN1006 fs block size 2.2.7-stable 3.0-current works should work 4K 4T-1 4T-1 4T-1 >4T 8K >32G 8T-1 >32G 32T-1 16K >128G 16T-1 >128G 32T-1 32K >512G 32T-1 >512G 64T-1 64K >2048G 64T-1 >2048G 128T-1 The statement before this table is: "The maximum size of a single ffs file is approximately 1G blocks (4TB) if the block size is 4K." Are this statement and these numbers still "correct" for 4.4-STABLE and/or -CURRENT? Thanks, -Jr -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | John Reynolds WCCG, CCE, CDS - Senior CAD Engineer | | Intel Corporation MS: CH6-210 Phone: 480-554-9092 pgr: 602-868-6512 | | jreynold@sedona.ch.intel.com http://www-aec.ch.intel.com/~jreynold/ | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Dec 14 12: 9:22 2001 Delivered-To: freebsd-fs@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id CA4D137B43B; Fri, 14 Dec 2001 12:08:40 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id fBEK63u92126; Fri, 14 Dec 2001 21:06:03 +0100 (CET) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id fBEJuStx034256; Fri, 14 Dec 2001 20:56:28 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id fBEJuRW11884; Fri, 14 Dec 2001 20:56:27 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.6/8.11.6) id fBEJuAc25407; Fri, 14 Dec 2001 20:56:10 +0100 (CET) (envelope-from ticso) Date: Fri, 14 Dec 2001 20:56:09 +0100 From: Bernd Walter To: John Reynolds~ Cc: questions@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: off_t governs the largest file size, correct? Message-ID: <20011214205608.E22150@cicely8.cicely.de> References: <15384.58121.214749.505032@chlx169.ch.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15384.58121.214749.505032@chlx169.ch.intel.com> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Dec 13, 2001 at 10:19:05AM -0700, John Reynolds~ wrote: > > Hi all, > > I searched the mailing list archives looking for this information and all I > found was a reference to a somewhat seemingly out-dated FAQ entry: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/install.html#AEN1006 > > fs block size 2.2.7-stable 3.0-current works should work > 4K 4T-1 4T-1 4T-1 >4T > 8K >32G 8T-1 >32G 32T-1 > 16K >128G 16T-1 >128G 32T-1 > 32K >512G 32T-1 >512G 64T-1 > 64K >2048G 64T-1 >2048G 128T-1 > > The statement before this table is: > > "The maximum size of a single ffs file is approximately 1G blocks (4TB) if > the block size is 4K." > > Are this statement and these numbers still "correct" for 4.4-STABLE and/or > -CURRENT? 8k blocksize works up to 8TB on alpha-current: ticso@cicely9# ls -al test -rw-r--r-- 1 root wheel 8388609048576 Dec 14 20:50 test I have tried 9000000 MB which failed. But keep in mind that the maximum size of a single filesystem is still 1TB, which restricts you to use sparse files. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Dec 14 12:33:13 2001 Delivered-To: freebsd-fs@freebsd.org Received: from root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 1154C37B416; Fri, 14 Dec 2001 12:33:10 -0800 (PST) Received: (from dg@localhost) by root.com (8.11.2/8.11.2) id fBEKMOf82181; Fri, 14 Dec 2001 12:22:24 -0800 (PST) (envelope-from dg) Date: Fri, 14 Dec 2001 12:22:24 -0800 From: David Greenman To: Bernd Walter Cc: John Reynolds~ , questions@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: off_t governs the largest file size, correct? Message-ID: <20011214122224.E81485@nexus.root.com> References: <15384.58121.214749.505032@chlx169.ch.intel.com> <20011214205608.E22150@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011214205608.E22150@cicely8.cicely.de>; from ticso@cicely8.cicely.de on Fri, Dec 14, 2001 at 08:56:09PM +0100 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >8k blocksize works up to 8TB on alpha-current: >ticso@cicely9# ls -al test >-rw-r--r-- 1 root wheel 8388609048576 Dec 14 20:50 test > >I have tried 9000000 MB which failed. > >But keep in mind that the maximum size of a single filesystem is still >1TB, which restricts you to use sparse files. Actually, the largest device size that FreeBSD (at least x86) supports is 1TB. This is because daddr_t (the type used to specify physical disk block addresses) is a signed int, which is 31bits worth of 512 byte blocks. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Dec 14 12:58:19 2001 Delivered-To: freebsd-fs@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 1D9BB37B405; Fri, 14 Dec 2001 12:58:15 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id fBEKt7u27329; Fri, 14 Dec 2001 21:55:07 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: David Greenman Cc: Bernd Walter , John Reynolds~ , questions@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: off_t governs the largest file size, correct? In-Reply-To: Your message of "Fri, 14 Dec 2001 12:22:24 PST." <20011214122224.E81485@nexus.root.com> Date: Fri, 14 Dec 2001 21:55:07 +0100 Message-ID: <27327.1008363307@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message <20011214122224.E81485@nexus.root.com>, David Greenman writes: >>8k blocksize works up to 8TB on alpha-current: >>ticso@cicely9# ls -al test >>-rw-r--r-- 1 root wheel 8388609048576 Dec 14 20:50 test >> >>I have tried 9000000 MB which failed. >> >>But keep in mind that the maximum size of a single filesystem is still >>1TB, which restricts you to use sparse files. > > Actually, the largest device size that FreeBSD (at least x86) supports >is 1TB. This is because daddr_t (the type used to specify physical disk >block addresses) is a signed int, which is 31bits worth of 512 byte blocks. This will be changed to 2^64 bytes as part of the DARPA contract I'm working on. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message