From owner-linux-xfs@oss.sgi.com Mon Mar 1 01:31:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Mar 2004 01:31:54 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i219VVKO027754 for ; Mon, 1 Mar 2004 01:31:31 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i219VVOA027753 for linux-xfs@oss.sgi.com; Mon, 1 Mar 2004 01:31:31 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i219VSKQ027739 for ; Mon, 1 Mar 2004 01:31:29 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i219KFKh027486; Mon, 1 Mar 2004 01:20:15 -0800 Date: Mon, 1 Mar 2004 01:20:15 -0800 Message-Id: <200403010920.i219KFKh027486@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 312] xfsprogs does not compile on AMD64/x86_64 X-Bugzilla-Reason: AssignedTo X-archive-position: 2281 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=312 ------- Additional Comments From kas@informatics.muni.cz 2004-01-03 01:20 PDT ------- > this unfortunately doesn't work either - if you run ldd on the resulting > xfs_repair for example, you'll see it has no longer statically linked in > the uuid library. You are right. Sorry for the confusion. > Would you be interested in hacking that up & testing the different options > a bit? Well, I am not an autoconf guru, so I think my changes may not be optimal. But I am definitely interested in testing the changes on my AMD64 system. Wouldn't the explicit --with-libuuid=/usr/lib64/libuuid.a be better than guessing the libuuid.a path? Also: can you explain why the "-static -luuid" does not work as I expect? Thanks, -Yenya ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Mar 1 05:06:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Mar 2004 05:07:01 -0800 (PST) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i21D6fKO007854 for ; Mon, 1 Mar 2004 05:06:44 -0800 Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by relay.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id i21D6eiv028801; Mon, 1 Mar 2004 14:06:41 +0100 (MET) Received: from boskoop.iwr.uni-heidelberg.de (boskoop.iwr.uni-heidelberg.de [129.206.120.167]) by mail.iwr.uni-heidelberg.de (8.12.10/8.12.9) with ESMTP id i21D6doi029877; Mon, 1 Mar 2004 14:06:39 +0100 (MET) Received: from iwr.uni-heidelberg.de (localhost [127.0.0.1]) by boskoop.iwr.uni-heidelberg.de (8.9.3p2/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA31705; Mon, 1 Mar 2004 14:06:38 +0100 Message-ID: <4043355E.9080208@iwr.uni-heidelberg.de> Date: Mon, 01 Mar 2004 14:06:38 +0100 From: Michael Lampe Organization: IWR Uni Heidelberg User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040117 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: linux-xfs@oss.sgi.com Subject: Re: 2.4.25 & xfs & ide write barriers References: <403E0A7A.3040505@iwr.uni-heidelberg.de> <20040229221924.GA731@frodo> In-Reply-To: <20040229221924.GA731@frodo> Content-Type: multipart/mixed; boundary="------------070400060200010308090500" X-archive-position: 2282 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Michael.Lampe@iwr.uni-heidelberg.de Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. --------------070400060200010308090500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nathan Scott wrote: > On Thu, Feb 26, 2004 at 04:02:18PM +0100, Michael Lampe wrote: > >>fs/xfs/linux/xfs_buf.c already has >> >> #ifdef RQ_WRITE_ORDERED >> if (flush) >> set_bit(BH_Ordered_Flush, &bufferlist[cnt-1]->b_state); >> #endif >> >>in _pagebuf_page_io. >> >>Is this all I need (I already have applied the ide write barrier patch) >>to safely use disk write back caching? >> > > > (which IDE write barrier patch is that, out of curiousity?) The one that SuSE ships with their latest kernel. Due to Jens Axboe, I think. (Attached.) > This stuff is untested by anyone here at SGI, so YMMV. It is > also not going to work in the presence of unwritten extents > (which were implemented after this change), some additional > code would be needed there. Pity, that. Beeing forced to disable write caching is major performance killer. -Michael --------------070400060200010308090500 Content-Type: text/plain; name="ide-write-barrier+ext3.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ide-write-barrier+ext3.patch" diff -ru /usr/src/linux-2.4.25/drivers/block/elevator.c linux-2.4.25/drivers/block/elevator.c --- /usr/src/linux-2.4.25/drivers/block/elevator.c Fri Jun 13 16:51:32 2003 +++ linux-2.4.25/drivers/block/elevator.c Wed Feb 25 18:23:18 2004 @@ -94,6 +94,9 @@ if (__rq->elevator_sequence <= 0) backmerge_only = 1; + if (__rq->cmd_flags & RQ_WRITE_ORDERED) + break; + if (__rq->waiting) continue; if (__rq->rq_dev != bh->b_rdev) @@ -156,6 +159,12 @@ entry = &q->queue_head; while ((entry = entry->prev) != head) { struct request *__rq = blkdev_entry_to_request(entry); + + /* + * we can neither merge nor insert before/with a flush + */ + if (__rq->cmd_flags & RQ_WRITE_ORDERED) + break; if (__rq->cmd != rw) continue; diff -ru /usr/src/linux-2.4.25/drivers/block/ll_rw_blk.c linux-2.4.25/drivers/block/ll_rw_blk.c --- /usr/src/linux-2.4.25/drivers/block/ll_rw_blk.c Fri Feb 13 15:43:59 2004 +++ linux-2.4.25/drivers/block/ll_rw_blk.c Wed Feb 25 18:47:36 2004 @@ -263,6 +263,32 @@ void blk_queue_make_request(request_queue_t * q, make_request_fn * mfn) { q->make_request_fn = mfn; + q->ordered = QUEUE_ORDERED_NONE; +} + +/** + * blk_queue_ordered - does this queue support ordered writes + * @q: the request queue + * @flag: see below + * + * Description: + * For journalled file systems, doing ordered writes on a commit + * block instead of explicitly doing wait_on_buffer (which is bad + * for performance) can be a big win. Block drivers supporting this + * feature should call this function and indicate so. + * + * SCSI drivers usually need to support ordered tags, while others + * may have to do a complete drive cache flush if they are using write + * back caching (or not and lying about it) + * + * With this in mind, the values are + * QUEUE_ORDERED_NONE: the default, doesn't support barrier + * QUEUE_ORDERED_TAG: supports ordered tags + * QUEUE_ORDERED_FLUSH: supports barrier through cache flush + **/ +void blk_queue_ordered(request_queue_t *q, int flag) +{ + q->ordered = flag; } /** @@ -577,6 +603,7 @@ list_del(&rq->queue); rl->count--; rl->pending[rw]++; + rq->cmd_flags = 0; rq->rq_status = RQ_ACTIVE; rq->cmd = rw; rq->special = NULL; @@ -989,12 +1016,27 @@ int latency; elevator_t *elevator = &q->elevator; int should_wake = 0; + int write_ordered = 0; + + /* check for barrier requests the device can't handle */ + if (buffer_ordered_tag(bh)) + write_ordered = QUEUE_ORDERED_TAG; + else if (buffer_ordered_flush(bh)) + write_ordered = QUEUE_ORDERED_FLUSH; + + if (write_ordered && q->ordered != write_ordered) { + if (buffer_ordered_hard(bh)) { + set_bit(BH_IO_OPNOTSUPP, &bh->b_state); + goto end_io; + } + write_ordered = 0; + } count = bh->b_size >> 9; sector = bh->b_rsector; sync = test_and_clear_bit(BH_Sync, &bh->b_state); - rw_ahead = 0; /* normal case; gets changed below for READA */ + latency = rw_ahead = 0; /* normal case; gets changed below for READA */ switch (rw) { case READA: #if 0 /* bread() misinterprets failed READA attempts as IO errors on SMP */ @@ -1003,7 +1045,8 @@ rw = READ; /* drop into READ */ case READ: case WRITE: - latency = elevator_request_latency(elevator, rw); + if (!write_ordered) + latency = elevator_request_latency(elevator, rw); break; default: BUG(); @@ -1136,6 +1179,9 @@ } /* fill up the request-info, and add it to the queue */ + if (write_ordered) + req->cmd_flags |= RQ_WRITE_ORDERED; + req->elevator_sequence = latency; req->cmd = rw; req->errors = 0; @@ -1637,3 +1683,4 @@ EXPORT_SYMBOL(blk_max_pfn); EXPORT_SYMBOL(blk_seg_merge_ok); EXPORT_SYMBOL(blk_nohighio); +EXPORT_SYMBOL(blk_queue_ordered); diff -ru /usr/src/linux-2.4.25/drivers/ide/ide-disk.c linux-2.4.25/drivers/ide/ide-disk.c --- /usr/src/linux-2.4.25/drivers/ide/ide-disk.c Fri Nov 28 19:26:20 2003 +++ linux-2.4.25/drivers/ide/ide-disk.c Wed Feb 25 18:23:18 2004 @@ -784,32 +784,7 @@ static int idedisk_end_request (ide_drive_t *drive, int uptodate) { - struct request *rq; - unsigned long flags; - int ret = 1; - - spin_lock_irqsave(&io_request_lock, flags); - rq = HWGROUP(drive)->rq; - - /* - * decide whether to reenable DMA -- 3 is a random magic for now, - * if we DMA timeout more than 3 times, just stay in PIO - */ - if (drive->state == DMA_PIO_RETRY && drive->retry_pio <= 3) { - drive->state = 0; - HWGROUP(drive)->hwif->ide_dma_on(drive); - } - - if (!end_that_request_first(rq, uptodate, drive->name)) { - add_blkdev_randomness(MAJOR(rq->rq_dev)); - blkdev_dequeue_request(rq); - HWGROUP(drive)->rq = NULL; - end_that_request_last(rq); - ret = 0; - } - - spin_unlock_irqrestore(&io_request_lock, flags); - return ret; + return ide_end_request(drive, uptodate); } static u8 idedisk_dump_status (ide_drive_t *drive, const char *msg, u8 stat) diff -ru /usr/src/linux-2.4.25/drivers/ide/ide-io.c linux-2.4.25/drivers/ide/ide-io.c --- /usr/src/linux-2.4.25/drivers/ide/ide-io.c Fri Nov 28 19:26:20 2003 +++ linux-2.4.25/drivers/ide/ide-io.c Wed Feb 25 18:23:18 2004 @@ -56,6 +56,38 @@ #include "ide_modes.h" + /* + * preempt pending requests, and store this cache flush for immediate + * execution + */ +static struct request *ide_queue_flush_cmd(ide_drive_t *drive, + struct request *rq, int post) +{ + struct request *flush_rq = &HWGROUP(drive)->wrq; + + list_del_init(&rq->queue); + + memset(drive->special_buf, 0, sizeof(drive->special_buf)); + + ide_init_drive_cmd(flush_rq); + + flush_rq->buffer = drive->special_buf; + flush_rq->special = rq; + flush_rq->buffer[0] = WIN_FLUSH_CACHE; + + if (drive->id->cfs_enable_2 & 0x2400) + flush_rq->buffer[0] = WIN_FLUSH_CACHE_EXT; + + if (!post) { + drive->doing_barrier = 1; + flush_rq->cmd_flags |= RQ_WRITE_PREFLUSH; + } else + flush_rq->cmd_flags |= RQ_WRITE_POSTFLUSH; + + list_add(&flush_rq->queue, &drive->queue.queue_head); + return flush_rq; +} + /* * ide_end_request - complete an IDE I/O * @drive: IDE device for the I/O @@ -85,10 +117,20 @@ if (!end_that_request_first(rq, uptodate, drive->name)) { add_blkdev_randomness(MAJOR(rq->rq_dev)); - blkdev_dequeue_request(rq); HWGROUP(drive)->rq = NULL; - end_that_request_last(rq); ret = 0; + + /* + * if this is a write barrier, flush the writecache before + * signalling completion of this request. + */ + if (rq->cmd_flags & RQ_WRITE_ORDERED) + ide_queue_flush_cmd(drive, rq, 1); + else { + blkdev_dequeue_request(rq); + end_that_request_last(rq); + } + } spin_unlock_irqrestore(&io_request_lock, flags); @@ -188,6 +230,33 @@ } spin_lock_irqsave(&io_request_lock, flags); blkdev_dequeue_request(rq); + + /* + * if a cache flush fails, disable ordered write support + */ + if (rq->cmd_flags & (RQ_WRITE_PREFLUSH | RQ_WRITE_POSTFLUSH)) { + struct request *real_rq = rq->special; + + /* + * should we forcibly disable the write back caching? + */ + if (err) { + printk("%s: cache flushing failed. disable write back cacheing for journalled file systems\n", drive->name); + blk_queue_ordered(&drive->queue, QUEUE_ORDERED_NONE); + } + + if (rq->cmd_flags & RQ_WRITE_POSTFLUSH) { + drive->doing_barrier = 0; + end_that_request_last(real_rq); + } else { + /* + * just indicate that we did the pre flush + */ + real_rq->cmd_flags |= RQ_WRITE_PREFLUSH; + list_add(&real_rq->queue, &drive->queue.queue_head); + } + } + HWGROUP(drive)->rq = NULL; end_that_request_last(rq); spin_unlock_irqrestore(&io_request_lock, flags); @@ -246,8 +315,11 @@ struct request *rq; u8 err; + if (drive == NULL) + return ide_stopped; + err = ide_dump_status(drive, msg, stat); - if (drive == NULL || (rq = HWGROUP(drive)->rq) == NULL) + if ((rq = HWGROUP(drive)->rq) == NULL) return ide_stopped; hwif = HWIF(drive); @@ -664,6 +736,15 @@ repeat: best = NULL; drive = hwgroup->drive; + + /* + * drive is doing pre-flush, ordered write, post-flush sequence. even + * though that is 3 requests, it must be seen as a single transaction. + * we must no preempt this drive until that is complete + */ + if (drive->doing_barrier) + return drive; + do { if (!blk_queue_empty(&drive->queue) && (!drive->sleep || time_after_eq(jiffies, drive->sleep))) { if (!best @@ -806,7 +887,18 @@ printk(KERN_ERR "%s: Huh? nuking plugged queue\n", drive->name); rq = blkdev_entry_next_request(&drive->queue.queue_head); + + /* + * if rq is a barrier write, issue pre cache flush if not + * already done + */ + if (rq->cmd_flags & RQ_WRITE_ORDERED) { + if (!(rq->cmd_flags & RQ_WRITE_PREFLUSH)) + rq = ide_queue_flush_cmd(drive, rq, 0); + } + hwgroup->rq = rq; + /* * Some systems have trouble with IDE IRQs arriving while * the driver is still setting things up. So, here we disable diff -ru /usr/src/linux-2.4.25/drivers/ide/ide-probe.c linux-2.4.25/drivers/ide/ide-probe.c --- /usr/src/linux-2.4.25/drivers/ide/ide-probe.c Fri Nov 28 19:26:20 2003 +++ linux-2.4.25/drivers/ide/ide-probe.c Wed Feb 25 18:23:18 2004 @@ -981,6 +981,9 @@ q->queuedata = HWGROUP(drive); blk_init_queue(q, do_ide_request); blk_queue_throttle_sectors(q, 1); + + if (drive->media == ide_disk) + blk_queue_ordered(&drive->queue, QUEUE_ORDERED_FLUSH); } #undef __IRQ_HELL_SPIN diff -ru /usr/src/linux-2.4.25/fs/jbd/commit.c linux-2.4.25/fs/jbd/commit.c --- /usr/src/linux-2.4.25/fs/jbd/commit.c Fri Feb 13 15:44:01 2004 +++ linux-2.4.25/fs/jbd/commit.c Wed Feb 25 18:23:19 2004 @@ -648,7 +648,15 @@ struct buffer_head *bh = jh2bh(descriptor); clear_bit(BH_Dirty, &bh->b_state); bh->b_end_io = journal_end_buffer_io_sync; + + /* if we're on an ide device, setting BH_Ordered_Flush + will force a write cache flush before and after the + commit block. Otherwise, it'll do nothing. */ + + set_bit(BH_Ordered_Flush, &bh->b_state); submit_bh(WRITE, bh); + clear_bit(BH_Ordered_Flush, &bh->b_state); + wait_on_buffer(bh); put_bh(bh); /* One for getblk() */ journal_unlock_journal_head(descriptor); diff -ru /usr/src/linux-2.4.25/include/linux/blkdev.h linux-2.4.25/include/linux/blkdev.h --- /usr/src/linux-2.4.25/include/linux/blkdev.h Sun Feb 22 19:19:21 2004 +++ linux-2.4.25/include/linux/blkdev.h Wed Feb 25 18:23:19 2004 @@ -32,6 +32,7 @@ kdev_t rq_dev; int cmd; /* READ or WRITE */ + unsigned long cmd_flags; int errors; unsigned long start_time; unsigned long sector; @@ -48,6 +49,10 @@ request_queue_t *q; }; +#define RQ_WRITE_ORDERED 1 /* ordered write */ +#define RQ_WRITE_PREFLUSH 2 /* pre-barrier flush */ +#define RQ_WRITE_POSTFLUSH 4 /* post-barrier flush */ + #include typedef int (merge_request_fn) (request_queue_t *q, @@ -145,6 +150,10 @@ int can_throttle:1; unsigned long bounce_pfn; + /* + * ordered write support + */ + char ordered; /* * Is meant to protect the queue in the future instead of @@ -174,6 +183,9 @@ } } +#define QUEUE_ORDERED_NONE 0 /* no support */ +#define QUEUE_ORDERED_TAG 1 /* supported by tags (fast) */ +#define QUEUE_ORDERED_FLUSH 2 /* supported by cache flush (ugh!) */ extern unsigned long blk_max_low_pfn, blk_max_pfn; #define BLK_BOUNCE_HIGH ((u64)blk_max_low_pfn << PAGE_SHIFT) @@ -244,6 +256,7 @@ extern void blk_cleanup_queue(request_queue_t *); extern void blk_queue_headactive(request_queue_t *, int); extern void blk_queue_throttle_sectors(request_queue_t *, int); +extern void blk_queue_ordered(request_queue_t *, int); extern void blk_queue_make_request(request_queue_t *, make_request_fn *); extern void generic_unplug_device(void *); extern inline int blk_seg_merge_ok(struct buffer_head *, struct buffer_head *); diff -ru /usr/src/linux-2.4.25/include/linux/fs.h linux-2.4.25/include/linux/fs.h --- /usr/src/linux-2.4.25/include/linux/fs.h Sun Feb 22 19:18:58 2004 +++ linux-2.4.25/include/linux/fs.h Wed Feb 25 18:35:59 2004 @@ -224,7 +224,11 @@ BH_JBD, /* 1 if it has an attached journal_head */ BH_Sync, /* 1 if the buffer is a sync read */ BH_Delay, /* 1 if the buffer is delayed allocate */ - + BH_Ordered_Tag, /* 1 if this buffer is a ordered write barrier */ + BH_Ordered_Flush,/* 1 if this buffer is a flush write barrier */ + BH_Ordered_Hard,/* 1 if barrier required by the caller */ + BH_IO_OPNOTSUPP,/* 1 if block layer rejected a barrier write */ + BH_PrivateStart,/* not a state bit, but the first bit available * for private allocation by other entities */ @@ -287,6 +291,9 @@ #define buffer_async(bh) __buffer_state(bh,Async) #define buffer_launder(bh) __buffer_state(bh,Launder) #define buffer_delay(bh) __buffer_state(bh,Delay) +#define buffer_ordered_tag(bh) __buffer_state(bh,Ordered_Tag) +#define buffer_ordered_hard(bh) __buffer_state(bh,Ordered_Hard) +#define buffer_ordered_flush(bh) __buffer_state(bh,Ordered_Flush) #define bh_offset(bh) ((unsigned long)(bh)->b_data & ~PAGE_MASK) diff -ru /usr/src/linux-2.4.25/include/linux/ide.h linux-2.4.25/include/linux/ide.h --- /usr/src/linux-2.4.25/include/linux/ide.h Sun Feb 22 19:19:59 2004 +++ linux-2.4.25/include/linux/ide.h Wed Feb 25 18:23:19 2004 @@ -747,6 +747,7 @@ unsigned ata_flash : 1; /* 1=present, 0=default */ unsigned dead : 1; /* 1=dead, no new attachments */ unsigned id_read : 1; /* 1=id read from disk 0 = synthetic */ + unsigned doing_barrier : 1; /* state, 1=currently doing flush */ unsigned addressing; /* : 3; * 0=28-bit * 1=48-bit @@ -792,6 +793,8 @@ int forced_lun; /* if hdxlun was given at boot */ int lun; /* logical unit */ int crc_count; /* crc counter to reduce drive speed */ + + char special_buf[4]; /* IDE_DRIVE_CMD, free use */ } ide_drive_t; typedef struct ide_pio_ops_s { --------------070400060200010308090500-- From owner-linux-xfs@oss.sgi.com Mon Mar 1 05:40:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Mar 2004 05:41:05 -0800 (PST) Received: from imo-m13.mx.aol.com (imo-m13.mx.aol.com [64.12.138.203]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i21DeuKO009139 for ; Mon, 1 Mar 2004 05:40:57 -0800 Received: from AndyLiebman@aol.com by imo-m13.mx.aol.com (mail_out_v36_r4.14.) id 4.1ed.1a502952 (3964) for ; Mon, 1 Mar 2004 08:40:49 -0500 (EST) From: AndyLiebman@aol.com Message-ID: <1ed.1a502952.2d749761@aol.com> Date: Mon, 1 Mar 2004 08:40:49 EST Subject: mkfs.xfs options with Linux RAID To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 for Windows sub 5006 X-archive-position: 2283 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: linux-xfs I have read in a couple of places that, in addition to setting the block size with the -b size=XXXX flag, when using xfs under Linux along with RAID, it's a good idea to set an xfs option with the -d flag (is it the suint, the swath, or something like that?) so that it's equal to the block size. Can somebody explain this? Which is the correct parameter to use? Why should these things be equal? And what happens when they're not equal? Thanks Andy Liebman From owner-linux-xfs@oss.sgi.com Mon Mar 1 06:03:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Mar 2004 06:04:29 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i21E3wKO009869 for ; Mon, 1 Mar 2004 06:03:59 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id C8052FBA3C; Mon, 1 Mar 2004 08:03:53 -0600 (CST) Date: Mon, 1 Mar 2004 06:03:53 -0800 From: Chris Wedgwood To: AndyLiebman@aol.com Cc: linux-xfs@oss.sgi.com Subject: Re: mkfs.xfs options with Linux RAID Message-ID: <20040301140353.GB752@dingdong.cryptoapps.com> References: <1ed.1a502952.2d749761@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1ed.1a502952.2d749761@aol.com> X-archive-position: 2284 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Mon, Mar 01, 2004 at 08:40:49AM -0500, AndyLiebman@aol.com wrote: > I have read in a couple of places that, in addition to setting the > block size with the -b size=XXXX flag, when using xfs under Linux > along with RAID, it's a good idea to set an xfs option with the -d > flag (is it the suint, the swath, or something like that?) so that > it's equal to the block size. Can somebody explain this? Which is > the correct parameter to use? Why should these things be equal? And > what happens when they're not equal? For software raid (md device) mkfs.xfs will usually detect this and set these options correctly for you. For hardware you probably want to set swidth to be the hardware stripe chunk size. I assume you would want to do this to spread the superblocks out evenly across all your spindles (I can't really think of any other good reason). From owner-linux-xfs@oss.sgi.com Mon Mar 1 07:05:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Mar 2004 07:05:49 -0800 (PST) Received: from stargate.coplanar.net (root@CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.112.162.124]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i21F5aKO011509 for ; Mon, 1 Mar 2004 07:05:40 -0800 Received: from coplanar.net (thunderdome.skynet.coplanar.net [192.168.7.3]) (authenticated bits=0) by stargate.coplanar.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id i21F5AhE029586 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 1 Mar 2004 10:05:15 -0500 Message-ID: <40435121.4050906@coplanar.net> Date: Mon, 01 Mar 2004 10:05:05 -0500 From: Jeremy Jackson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Michael Lampe CC: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: 2.4.25 & xfs & ide write barriers References: <403E0A7A.3040505@iwr.uni-heidelberg.de> <20040229221924.GA731@frodo> <4043355E.9080208@iwr.uni-heidelberg.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (stargate.coplanar.net: domain of jerj@coplanar.net designates 192.168.7.3 as SASL permitted sender) X-archive-position: 2285 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Michael Lampe wrote: >>> Is this all I need (I already have applied the ide write barrier patch) >>> to safely use disk write back caching? >>> >> >> >> (which IDE write barrier patch is that, out of curiousity?) > > > The one that SuSE ships with their latest kernel. Due to Jens Axboe, I > think. (Attached.) > >> This stuff is untested by anyone here at SGI, so YMMV. It is >> also not going to work in the presence of unwritten extents >> (which were implemented after this change), some additional >> code would be needed there. > > > Pity, that. Beeing forced to disable write caching is major performance > killer. > > -Michael I think write back caching is a lame IDE performance hack. SCSI disks use TCQ to achieve write performance without compromising data integrity. (XFS guys - Linux does this, right?) I wonder if it would be more productive to pursue the IDE-TCQ stuff that's coming down the pipe. Regards, Jeremy Jackson From owner-linux-xfs@oss.sgi.com Mon Mar 1 07:46:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Mar 2004 07:47:02 -0800 (PST) Received: from corsmtp01-e.anixter.com (corsmtp01-e.anixter.com [12.165.151.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i21FkvKO013022 for ; Mon, 1 Mar 2004 07:46:58 -0800 Received: from corsmtp01.anixter.com by corsmtp01-e.anixter.com via smtpd (for oss.sgi.com [192.48.159.27]) with ESMTP; Mon, 1 Mar 2004 09:46:57 -0600 To: linux-xfs@oss.sgi.com Subject: Please remove me from your mailing list MIME-Version: 1.0 Message-ID: From: David.Grudek@anixter.com Date: Mon, 1 Mar 2004 09:45:10 -0600 Content-Type: text/plain; charset="us-ascii" X-archive-position: 2286 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: David.Grudek@anixter.com Precedence: bulk X-list: linux-xfs Please remove me from your mailing list From owner-linux-xfs@oss.sgi.com Mon Mar 1 09:10:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Mar 2004 09:10:27 -0800 (PST) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i21HAAKO018020 for ; Mon, 1 Mar 2004 09:10:10 -0800 Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by relay.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id i21HA5iv001825; Mon, 1 Mar 2004 18:10:05 +0100 (MET) Received: from boskoop.iwr.uni-heidelberg.de (boskoop.iwr.uni-heidelberg.de [129.206.120.167]) by mail.iwr.uni-heidelberg.de (8.12.10/8.12.9) with ESMTP id i21HA3oi008002; Mon, 1 Mar 2004 18:10:03 +0100 (MET) Received: from iwr.uni-heidelberg.de (localhost [127.0.0.1]) by boskoop.iwr.uni-heidelberg.de (8.9.3p2/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA07562; Mon, 1 Mar 2004 18:10:03 +0100 Message-ID: <40436E6A.5020800@iwr.uni-heidelberg.de> Date: Mon, 01 Mar 2004 18:10:02 +0100 From: Michael Lampe Organization: IWR Uni Heidelberg User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040117 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeremy Jackson CC: linux-xfs@oss.sgi.com Subject: Re: 2.4.25 & xfs & ide write barriers References: <403E0A7A.3040505@iwr.uni-heidelberg.de> <20040229221924.GA731@frodo> <4043355E.9080208@iwr.uni-heidelberg.de> <40435121.4050906@coplanar.net> In-Reply-To: <40435121.4050906@coplanar.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2287 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Michael.Lampe@iwr.uni-heidelberg.de Precedence: bulk X-list: linux-xfs Jeremy Jackson wrote: > SCSI disks > use TCQ to achieve write performance without compromising data > integrity. Ordered queue tags can be used to implement write barriers. > (XFS guys - Linux does this, right?) No. (I'm not an XFS guy, though.) -Michael From owner-linux-xfs@oss.sgi.com Mon Mar 1 09:37:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Mar 2004 09:37:40 -0800 (PST) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i21HbKKO018789 for ; Mon, 1 Mar 2004 09:37:22 -0800 Received: from darke.mpc.local ([172.16.11.6] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 4.24) id 1AxrLZ-0004vM-Eq; Mon, 01 Mar 2004 17:36:53 +0000 Message-ID: <404374B5.B13227F4@moving-picture.com> Date: Mon, 01 Mar 2004 17:36:53 +0000 From: James Pearson Organization: Moving Picture Company X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: Christoph Hellwig , Eric Sandeen CC: linux-xfs Subject: Re: df and "Value too large for defined data type" References: <403DF97D.C717302E@moving-picture.com> <1077904776.7024.5.camel@stout.americas.sgi.com> <20040227181914.A3175@infradead.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Disclaimer: This email and any attachments are confidential, may be legally X-Disclaimer: privileged and intended solely for the use of addressee. If you X-Disclaimer: are not the intended recipient of this message, any disclosure, X-Disclaimer: copying, distribution or any action taken in reliance on it is X-Disclaimer: strictly prohibited and may be unlawful. If you have received X-Disclaimer: this message in error, please notify the sender and delete all X-Disclaimer: copies from your system. X-Disclaimer: X-Disclaimer: Email may be susceptible to data corruption, interception and X-Disclaimer: unauthorised amendment, and we do not accept liability for any X-Disclaimer: such corruption, interception or amendment or the consequences X-Disclaimer: thereof. X-archive-position: 2288 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james-p@moving-picture.com Precedence: bulk X-list: linux-xfs Christoph Hellwig wrote: > > On Fri, Feb 27, 2004 at 11:59:36AM -0600, Eric Sandeen wrote: > > the 2.4 statfs interface is 32 bits; I think that until you upgrade the > > server to 2.6, and (as Christoph tells me) you'll also need a very > > recent glibc to take advantage of it. > > > > On a large filesystem, xfs easily wraps around the ints in the statfs > > structure. > > Well, in the case of free inodes we might be a bit over-eager and should > just return some random lower value. Not that it really matters with > dynamically allocated inodes.. It looks like some of the ints in statfs under 2.4.X (on i386) will overflow when you have just over half a terrabyte of free space on an XFS file system - which I guess is not that big nowadays ... Here is a simple patch that appears to work OK in my situation - I guess there would still be an overflow problem if the number of used inodes reached 2 billion ... James Pearson *** xfs_vfsops.c.dist Tue Sep 16 12:14:03 2003 --- xfs_vfsops.c Mon Mar 1 16:36:35 2004 *************** *** 788,799 **** lsize = sbp->sb_logstart ? sbp->sb_logblocks : 0; statp->f_blocks = sbp->sb_dblocks - lsize; statp->f_bfree = statp->f_bavail = sbp->sb_fdblocks; ! fakeinos = statp->f_bfree << sbp->sb_inopblog; #if XFS_BIG_FILESYSTEMS fakeinos += mp->m_inoadd; #endif statp->f_files = ! MIN(sbp->sb_icount + fakeinos, (__uint64_t)XFS_MAXINUMBER); if (mp->m_maxicount) #if XFS_BIG_FILESYSTEMS if (!mp->m_inoadd) --- 788,799 ---- lsize = sbp->sb_logstart ? sbp->sb_logblocks : 0; statp->f_blocks = sbp->sb_dblocks - lsize; statp->f_bfree = statp->f_bavail = sbp->sb_fdblocks; ! fakeinos = (__uint64_t) statp->f_bfree << sbp->sb_inopblog; #if XFS_BIG_FILESYSTEMS fakeinos += mp->m_inoadd; #endif statp->f_files = ! MIN(sbp->sb_icount + fakeinos, (__uint64_t)((1ULL << 31) - 1ULL)); if (mp->m_maxicount) #if XFS_BIG_FILESYSTEMS if (!mp->m_inoadd) From owner-linux-xfs@oss.sgi.com Mon Mar 1 23:23:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Mar 2004 23:23:58 -0800 (PST) Received: from thebsh.namesys.com (thebsh.namesys.com [212.16.7.65]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i227NTKO011941 for ; Mon, 1 Mar 2004 23:23:31 -0800 Received: (qmail 27311 invoked from network); 2 Mar 2004 07:23:23 -0000 Received: from bitshadow.namesys.com (HELO namesys.com) (212.16.7.71) by thebsh.namesys.com with SMTP; 2 Mar 2004 07:23:23 -0000 Message-ID: <4044366B.3000405@namesys.com> Date: Tue, 02 Mar 2004 10:23:23 +0300 From: Hans Reiser User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Nelson CC: linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 References: <4044119D.6050502@andrew.cmu.edu> In-Reply-To: <4044119D.6050502@andrew.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2289 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: reiser@namesys.com Precedence: bulk X-list: linux-xfs Are you sure your benchmark is large enough to not fit into memory, particularly the first stages of it? It looks like not. reiser4 is much faster on tasks like untarring enough files to not fit into ram, but (despite your words) your results seem to show us as slower unless I misread them.... Reiser4 performs best on benchmarks that use the disk drive, and we usually only run benchmarks that use the disk drive. Hans Peter Nelson wrote: > I recently decided to reinstall my system and at the same time try a > new file system. Trying to decide what filesystem to use I found a few > benchmarks but either they don't compare all available fs's, are too > synthetic (copy a source tree multiple times or raw i/o), or are meant > for servers/databases (like Bonnie++). The two most file system > intensive tasks I do regularly are `apt-get upgrade` waiting for the > packages to extract and set themselves up and messing around with the > kernel so I benchmarked these. To make it more realistic I installed > ccache and did two compiles, one to fill the cache and a second using > the full cache. > > The tests I timed (in order): > * Debootstrap to install base Debian system > * Extract the kernel source > * Run `make all` using the defconfig and an empty ccache > * Copy the entire new directory tree > * Run `make clean` > * Run `make all` again, this time using the filled ccache > * Deleting the entire directory tree > > Here is summary of the results based upon what I am calling "dead" > time calculated as `total time - user time`. You should be able to script out the user time. > As you can see in the full results on my website the user time is > almost identical between filesystems, so I believe this is an accurate > comparison. The dead time is then normalized using ext2 as a baseline > (> 1 means it took that many times longer than ext2). > > FS deb tar make cp clean make2 rm total > ext2 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 > ext3 1.12 2.47 0.88 1.16 0.91 0.93 3.01 1.13 > jfs 1.64 2.18 1.22 1.90 1.60 1.19 12.84 1.79 > reiser 1.12 1.99 1.05 1.41 0.92 1.56 1.42 1.28 > reiser4 2.69 1.87 1.80 0.63 1.33 2.71 4.14 1.83 > xfs 1.06 1.99 0.97 1.67 0.78 1.03 10.27 1.43 > > Some observations of mine > * Ext2 is still overall the fastest but I think the margin is small > enough that a journal is well worth it > * Ext3, ReiserFS, and XFS all perform similarly and almost up to > Ext2 except: > o XFS takes an abnormally long time to do a large rm even > though it is very fast at a kernel `make clean` > o ReiserFS is significantly slower at the second make (from > ccache) > * JFS is fairly slow overall > * Reiser4 is exceptionally fast at synthetic benchmarks like copying > the system and untaring, but is very slow at the real-world > debootstrap and kernel compiles. > * Though I didn't benchmark it, ReiserFS sometimes takes a second or > two to mount and Reiser4 sometimes takes a second or two to unmount > while all other filesystem's are instantaneous. > > Originally I had planned on using Reiser4 because of the glowing > reviews they give themselves but I'm simply not seeing it. It might be > that my Reiser4 is somehow broken but I don't think so. Based on these > results I personally am now going with XFS as it's faster than > ReiserFS in the real-world benchmarks and my current Ext3 partition's > performance is getting worse and worse. > > Full benchmark results, system information, and the script I used to > run these tests are available from my website here: > > > Feel free to comment, suggest improvements to my script, or run the > test yourself. > -Peter Nelson > > -- Hans From owner-linux-xfs@oss.sgi.com Tue Mar 2 01:30:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Mar 2004 01:30:56 -0800 (PST) Received: from corpmail.outblaze.com (corpmail.outblaze.com [203.86.166.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i229UNKO017628 for ; Tue, 2 Mar 2004 01:30:25 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by corpmail.outblaze.com (Postfix) with ESMTP id D164437ACB; Tue, 2 Mar 2004 09:30:20 +0000 (GMT) Received: from linuxmail.org (210-177-227-130.outblaze.com [210.177.227.130]) by corpmail.outblaze.com (Postfix) with ESMTP id 305D916DD89; Tue, 2 Mar 2004 09:30:20 +0000 (GMT) Message-ID: <4044542C.2020102@linuxmail.org> Date: Tue, 02 Mar 2004 17:30:20 +0800 From: Feizhou User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Feizhou Cc: Danny Cox , XFS Mailing List Subject: Re: Performance problem with xfs References: <403F1934.3020701@linuxmail.org> <1077894047.25678.7.camel@pip> <40403DC6.7070501@linuxmail.org> In-Reply-To: <40403DC6.7070501@linuxmail.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.11; VAE: 6.24.0.5; VDF: 6.24.0.32; host: corpmail.outblaze.com) X-archive-position: 2290 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: feizhou@linuxmail.org Precedence: bulk X-list: linux-xfs Unfortunately I did not have the time to pin down what improved things but upgrading the processor and pulling out 1G RAM from the installed 2G RAM improved performance and stability of the box. also a tweak to /proc/sys/vm/kswapd was made. kswapd doesn't even show up as using cpu anymore now and I don't have blocked processes anymore. From owner-linux-xfs@oss.sgi.com Tue Mar 2 08:34:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Mar 2004 08:34:24 -0800 (PST) Received: from smtp2.andrew.cmu.edu (SMTP2.andrew.cmu.edu [128.2.10.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i22GYKKO012466 for ; Tue, 2 Mar 2004 08:34:20 -0800 Received: from andrew.cmu.edu (RUFUS.RES.cmu.edu [128.2.166.130]) (user=pnelson mech=PLAIN (0 bits)) by smtp2.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i22GYGn6030798 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 2 Mar 2004 11:34:16 -0500 Message-ID: <4044B787.7080301@andrew.cmu.edu> Date: Tue, 02 Mar 2004 11:34:15 -0500 From: Peter Nelson User-Agent: Mozilla Thunderbird 0.5 (X11/20040221) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hans Reiser CC: linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 References: <4044119D.6050502@andrew.cmu.edu> <4044366B.3000405@namesys.com> In-Reply-To: <4044366B.3000405@namesys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2291 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pnelson@andrew.cmu.edu Precedence: bulk X-list: linux-xfs Hans Reiser wrote: > Are you sure your benchmark is large enough to not fit into memory, > particularly the first stages of it? It looks like not. reiser4 is > much faster on tasks like untarring enough files to not fit into ram, > but (despite your words) your results seem to show us as slower unless > I misread them.... I'm pretty sure most of the benchmarking I am doing fits into ram, particularly because my system has 1GB of it, but I see this as realistic. When I download a bunch of debs (or rpms or the kernel) I'm probably going to install them directly with them still in the file cache. Same with rebuilding the kernel after working on it. For untarring reiser4 is the fastest other than ext2. A somewhat less ambiguous conclusion: * Reiser4 is exceptionally fast at copying the system and the fastest other than Ext2 at untaring, but is very slow at the real-world debootstrap and kernel compiles. > Reiser4 performs best on benchmarks that use the disk drive, and we > usually only run benchmarks that use the disk drive. I'm confused as to why performing a benchmark out of cache as opposed to on disk would hurt performance? > Here is summary of the results based upon what I am calling "dead" > time calculated as `total time - user time`. > > You should be able to script out the user time. I'm working with a friend of mine here at CMU doing hard drive research to create a execution trace and test that directly instead of performing all of the script actions. -Peter Nelson From owner-linux-xfs@oss.sgi.com Tue Mar 2 11:02:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Mar 2004 11:02:13 -0800 (PST) Received: from web60003.mail.yahoo.com (web60003.mail.yahoo.com [216.109.116.226]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i22J2AKO018238 for ; Tue, 2 Mar 2004 11:02:10 -0800 Message-ID: <20040302190205.95064.qmail@web60003.mail.yahoo.com> Received: from [206.135.227.186] by web60003.mail.yahoo.com via HTTP; Tue, 02 Mar 2004 11:02:05 PST Date: Tue, 2 Mar 2004 11:02:05 -0800 (PST) From: Eric Jordan Reply-To: eric@gmfx.com Subject: XFS and Redhat Linux To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2292 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: flatspinvfx@yahoo.com Precedence: bulk X-list: linux-xfs Good morning, I am preparing to install Redhat 9 on a system which is currently running Mandrake Linux with XFS. Am I going to have to reformat the drive array atteched to the system for this transition to work? I am proceeding ahead either way. There's no turning back now. Thanks Eric ===== -- Eric Jordan 310-266-9290 "I have not failed. I've just found 10,000 ways that won't work." - Thomas Edison __________________________________ Do you Yahoo!? Yahoo! Search - Find what you’re looking for faster http://search.yahoo.com From owner-linux-xfs@oss.sgi.com Tue Mar 2 11:08:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Mar 2004 11:08:35 -0800 (PST) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i22J8VKO019112 for ; Tue, 2 Mar 2004 11:08:32 -0800 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i22J8SPh000443; Tue, 2 Mar 2004 20:08:28 +0100 Message-ID: <4044DB88.2080008@stesmi.com> Date: Tue, 02 Mar 2004 20:07:52 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040219 X-Accept-Language: en-us, en MIME-Version: 1.0 To: eric@gmfx.com CC: linux-xfs@oss.sgi.com Subject: Re: XFS and Redhat Linux References: <20040302190205.95064.qmail@web60003.mail.yahoo.com> In-Reply-To: <20040302190205.95064.qmail@web60003.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2293 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Hi. > I am preparing to install Redhat 9 on a system which > is currently running Mandrake Linux with XFS. Am I > going to have to reformat the drive array atteched to > the system for this transition to work? If you use standard RH9 installer - yes. If you use either the CD ISO with XFS support - no. If you use the DVD ISO with XFS support - no. But I would recommend using Fedora Core 1 instead. I only know of my DVD which you can find at ftp://ftp.uninett.no/pub/Linux/RH-XFS-DVD/ It contains FC1 + many updates + XFS support. You DO know FC1 can be seen as "RedHat 9.1" or "RedHat 10" as it's basically the same but updated. > I am proceeding ahead either way. There's no turning > back now. Good luck. // Stefan From owner-linux-xfs@oss.sgi.com Tue Mar 2 14:32:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Mar 2004 14:32:11 -0800 (PST) Received: from mail.gurulabs.com ([66.62.77.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i22MW7KO032090 for ; Tue, 2 Mar 2004 14:32:07 -0800 Received: from [10.2.3.128] (dhcp128.glwlan.gurulabs.com [10.2.3.128]) by mail.gurulabs.com (Postfix) with ESMTP id 1816477B8; Tue, 2 Mar 2004 15:32:07 -0700 (MST) Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 From: Dax Kelson To: Peter Nelson Cc: Hans Reiser , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com In-Reply-To: <4044B787.7080301@andrew.cmu.edu> References: <4044119D.6050502@andrew.cmu.edu> <4044366B.3000405@namesys.com> <4044B787.7080301@andrew.cmu.edu> Content-Type: text/plain Message-Id: <1078266793.8582.24.camel@mentor.gurulabs.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Tue, 02 Mar 2004 15:33:13 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 2295 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dax@gurulabs.com Precedence: bulk X-list: linux-xfs On Tue, 2004-03-02 at 09:34, Peter Nelson wrote: > Hans Reiser wrote: > > I'm confused as to why performing a benchmark out of cache as opposed to > on disk would hurt performance? My understanding (which could be completely wrong) is that reieserfs v3 and v4 are algorithmically more complex than ext2 or ext3. Reiserfs spends more CPU time to make the eventual ondisk operations more efficient/faster. When operating purely or mostly out of ram, the higher CPU utilization of reiserfs hurts performance compared to ext2 and ext3. When your system I/O utilization exceeds cache size and your disks starting getting busy, the CPU time previously invested by reiserfs pays big dividends and provides large performance gains versus more simplistic filesystems. In other words, the CPU penalty paid by reiserfs v3/v4 is more than made up for by the resultant more efficient disk operations. Reiserfs trades CPU for disk performance. In a nutshell, if you have more memory than you know what do to with, stick with ext3. If you spend all your time waiting for disk operations to complete, go with reiserfs. Dax Kelson Guru Labs From owner-linux-xfs@oss.sgi.com Tue Mar 2 14:31:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Mar 2004 14:31:51 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i22MVcKO032051 for ; Tue, 2 Mar 2004 14:31:38 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i22MVc4q032050 for linux-xfs@oss.sgi.com; Tue, 2 Mar 2004 14:31:38 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i22MVaKS032034 for ; Tue, 2 Mar 2004 14:31:36 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i22Lkp66030758; Tue, 2 Mar 2004 13:46:51 -0800 Date: Tue, 2 Mar 2004 13:46:51 -0800 Message-Id: <200403022146.i22Lkp66030758@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 312] xfsprogs does not compile on AMD64/x86_64 X-Bugzilla-Reason: AssignedTo X-archive-position: 2294 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=312 nathans@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|xfs-master@oss.sgi.com |nathans@sgi.com ------- Additional Comments From nathans@sgi.com 2004-02-03 13:46 PDT ------- > Well, I am not an autoconf guru, so I think my changes may not be optimal. > But I am definitely interested in testing the changes on my AMD64 system. OK, I hacked something up - I'll send you a patch to try. > Wouldn't the explicit --with-libuuid=/usr/lib64/libuuid.a be better than > guessing the libuuid.a path? configure scripts shouldn't require intervention by default if possible, so I'd much prefer this to just work. > Also: can you explain why the "-static -luuid" does not work as I expect? *shrug*, I don't know why. cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Mar 2 14:37:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Mar 2004 14:37:47 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i22MbgKO000430 for ; Tue, 2 Mar 2004 14:37:42 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i22MbbRM001263 for ; Tue, 2 Mar 2004 16:37:37 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i22Mba6S34824504 for ; Tue, 2 Mar 2004 16:37:37 -0600 (CST) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i22MbZXa319017; Tue, 2 Mar 2004 16:37:35 -0600 (CST) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id i22MbVKW027254; Tue, 2 Mar 2004 16:37:32 -0600 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id i22MbVN3027252; Tue, 2 Mar 2004 16:37:31 -0600 Date: Tue, 2 Mar 2004 16:37:31 -0600 From: Eric Sandeen Message-Id: <200403022237.i22MbVN3027252@penguin.americas.sgi.com> Subject: TAKE 910494 - Fix quota/dmapi module builds X-archive-position: 2296 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Date: Tue Mar 2 14:37:09 PST 2004 Workarea: penguin.americas.sgi.com:/src/eric/linux-2.4.x Inspected by: hch The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:167775a fs/xfs/linux-2.6/xfs_ksyms.c - 1.5 - export d_alloc_anon for dmapi module fs/xfs/linux-2.4/xfs_ksyms.c - 1.4 - export d_alloc_anon for dmapi module Modid: 2.4.x-xfs:linux:167775b fs/Config.in - 1.4 - make quota/dmapi tristate (module build) option From owner-linux-xfs@oss.sgi.com Tue Mar 2 15:14:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Mar 2004 15:14:24 -0800 (PST) Received: from khan.acc.umu.se (postfix@khan.acc.umu.se [130.239.18.139]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i22NE5KO001353 for ; Tue, 2 Mar 2004 15:14:05 -0800 Received: from localhost (localhost [127.0.0.1]) by amavisd-new (Postfix) with ESMTP id 5C5A6D276; Tue, 2 Mar 2004 23:47:59 +0100 (MET) Received: by khan.acc.umu.se (Postfix, from userid 23136) id 3CAAAD2D8; Tue, 2 Mar 2004 23:47:58 +0100 (MET) Date: Tue, 2 Mar 2004 23:47:58 +0100 From: David Weinehall To: Dax Kelson Cc: Peter Nelson , Hans Reiser , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 Message-ID: <20040302224758.GK19111@khan.acc.umu.se> Mail-Followup-To: Dax Kelson , Peter Nelson , Hans Reiser , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@oss.software.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com References: <4044119D.6050502@andrew.cmu.edu> <4044366B.3000405@namesys.com> <4044B787.7080301@andrew.cmu.edu> <1078266793.8582.24.camel@mentor.gurulabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1078266793.8582.24.camel@mentor.gurulabs.com> User-Agent: Mutt/1.4.1i X-Accept-Language: Swedish, English X-GPG-Fingerprint: 7ACE 0FB0 7A74 F994 9B36 E1D1 D14E 8526 DC47 CA16 X-GPG-Key: http://www.acc.umu.se/~tao/files/pubkey_dc47ca16.gpg.asc X-Virus-Scanned: by amavisd-new at acc.umu.se X-archive-position: 2297 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tao@acc.umu.se Precedence: bulk X-list: linux-xfs On Tue, Mar 02, 2004 at 03:33:13PM -0700, Dax Kelson wrote: > On Tue, 2004-03-02 at 09:34, Peter Nelson wrote: > > Hans Reiser wrote: > > > > I'm confused as to why performing a benchmark out of cache as opposed to > > on disk would hurt performance? > > My understanding (which could be completely wrong) is that reieserfs v3 > and v4 are algorithmically more complex than ext2 or ext3. Reiserfs > spends more CPU time to make the eventual ondisk operations more > efficient/faster. > > When operating purely or mostly out of ram, the higher CPU utilization > of reiserfs hurts performance compared to ext2 and ext3. > > When your system I/O utilization exceeds cache size and your disks > starting getting busy, the CPU time previously invested by reiserfs pays > big dividends and provides large performance gains versus more > simplistic filesystems. > > In other words, the CPU penalty paid by reiserfs v3/v4 is more than made > up for by the resultant more efficient disk operations. Reiserfs trades > CPU for disk performance. > > In a nutshell, if you have more memory than you know what do to with, > stick with ext3. If you spend all your time waiting for disk operations > to complete, go with reiserfs. Or rather, if you have more memory than you know what to do with, use ext3. If you have more CPU power than you know what to do with, use ReiserFS[34]. On slower machines, I generally prefer a little slower I/O rather than having the entire system sluggish because of higher CPU-usage. Regards: David Weinehall -- /) David Weinehall /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/ (/ Full colour fire (/ From owner-linux-xfs@oss.sgi.com Tue Mar 2 17:31:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Mar 2004 17:31:20 -0800 (PST) Received: from visualfx.animezone.org (CPE006097a16e12-CM400026313227.cpe.net.cable.rogers.com [24.101.19.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i231V6KO006146 for ; Tue, 2 Mar 2004 17:31:07 -0800 Received: from animezone.org (picasso.animezone.org [192.168.68.5]) by visualfx.animezone.org (8.12.8/8.12.8) with ESMTP id i231Hpvt002241; Tue, 2 Mar 2004 20:17:52 -0500 Message-ID: <40453538.8050103@animezone.org> Date: Tue, 02 Mar 2004 20:30:32 -0500 From: Andrew Ho User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030509 X-Accept-Language: en-us, en, zh-hk, zh, zh-cn MIME-Version: 1.0 To: David Weinehall CC: Dax Kelson , Peter Nelson , Hans Reiser , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 References: <4044119D.6050502@andrew.cmu.edu> <4044366B.3000405@namesys.com> <4044B787.7080301@andrew.cmu.edu> <1078266793.8582.24.camel@mentor.gurulabs.com> <20040302224758.GK19111@khan.acc.umu.se> In-Reply-To: <20040302224758.GK19111@khan.acc.umu.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2298 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrewho@animezone.org Precedence: bulk X-list: linux-xfs XFS is the best filesystem. David Weinehall wrote: >On Tue, Mar 02, 2004 at 03:33:13PM -0700, Dax Kelson wrote: > > >>On Tue, 2004-03-02 at 09:34, Peter Nelson wrote: >> >> >>>Hans Reiser wrote: >>> >>>I'm confused as to why performing a benchmark out of cache as opposed to >>>on disk would hurt performance? >>> >>> >>My understanding (which could be completely wrong) is that reieserfs v3 >>and v4 are algorithmically more complex than ext2 or ext3. Reiserfs >>spends more CPU time to make the eventual ondisk operations more >>efficient/faster. >> >>When operating purely or mostly out of ram, the higher CPU utilization >>of reiserfs hurts performance compared to ext2 and ext3. >> >>When your system I/O utilization exceeds cache size and your disks >>starting getting busy, the CPU time previously invested by reiserfs pays >>big dividends and provides large performance gains versus more >>simplistic filesystems. >> >>In other words, the CPU penalty paid by reiserfs v3/v4 is more than made >>up for by the resultant more efficient disk operations. Reiserfs trades >>CPU for disk performance. >> >>In a nutshell, if you have more memory than you know what do to with, >>stick with ext3. If you spend all your time waiting for disk operations >>to complete, go with reiserfs. >> >> > >Or rather, if you have more memory than you know what to do with, use >ext3. If you have more CPU power than you know what to do with, use >ReiserFS[34]. > >On slower machines, I generally prefer a little slower I/O rather than >having the entire system sluggish because of higher CPU-usage. > > >Regards: David Weinehall > > From owner-linux-xfs@oss.sgi.com Tue Mar 2 18:17:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Mar 2004 18:17:49 -0800 (PST) Received: from khan.acc.umu.se (postfix@khan.acc.umu.se [130.239.18.139]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i232HOKO007193 for ; Tue, 2 Mar 2004 18:17:25 -0800 Received: from localhost (localhost [127.0.0.1]) by amavisd-new (Postfix) with ESMTP id 405AFD2C9; Wed, 3 Mar 2004 02:41:16 +0100 (MET) Received: by khan.acc.umu.se (Postfix, from userid 23136) id 34110D2D9; Wed, 3 Mar 2004 02:41:15 +0100 (MET) Date: Wed, 3 Mar 2004 02:41:15 +0100 From: David Weinehall To: Andrew Ho Cc: Dax Kelson , Peter Nelson , Hans Reiser , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 Message-ID: <20040303014115.GP19111@khan.acc.umu.se> Mail-Followup-To: Andrew Ho , Dax Kelson , Peter Nelson , Hans Reiser , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com References: <4044119D.6050502@andrew.cmu.edu> <4044366B.3000405@namesys.com> <4044B787.7080301@andrew.cmu.edu> <1078266793.8582.24.camel@mentor.gurulabs.com> <20040302224758.GK19111@khan.acc.umu.se> <40453538.8050103@animezone.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40453538.8050103@animezone.org> User-Agent: Mutt/1.4.1i X-Accept-Language: Swedish, English X-GPG-Fingerprint: 7ACE 0FB0 7A74 F994 9B36 E1D1 D14E 8526 DC47 CA16 X-GPG-Key: http://www.acc.umu.se/~tao/files/pubkey_dc47ca16.gpg.asc X-Virus-Scanned: by amavisd-new at acc.umu.se X-archive-position: 2299 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: david@southpole.se Precedence: bulk X-list: linux-xfs On Tue, Mar 02, 2004 at 08:30:32PM -0500, Andrew Ho wrote: > XFS is the best filesystem. Well it'd better be, it's 10 times the size of ext3, 5 times the size of ReiserFS and 3.5 times the size of JFS. And people say size doesn't matter. Regards: David Weinehall -- /) David Weinehall /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/ (/ Full colour fire (/ From owner-linux-xfs@oss.sgi.com Tue Mar 2 18:41:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Mar 2004 18:41:27 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i232f6KO009532 for ; Tue, 2 Mar 2004 18:41:07 -0800 Received: from hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 22BDB2817BF; Wed, 3 Mar 2004 03:41:00 +0100 (CET) Received: from brahms.suse.de (brahms.suse.de [10.11.0.20]) by hermes.suse.de (Postfix) with ESMTP id 7423C8993; Wed, 3 Mar 2004 03:40:59 +0100 (CET) Received: by brahms.suse.de (Postfix, from userid 14000) id 04BA12D129; Wed, 3 Mar 2004 03:39:26 +0100 (CET) To: David Weinehall Cc: Dax Kelson , Peter Nelson , Hans Reiser , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 References: <4044119D.6050502@andrew.cmu.edu> <4044366B.3000405@namesys.com> <4044B787.7080301@andrew.cmu.edu> <1078266793.8582.24.camel@mentor.gurulabs.com> <20040302224758.GK19111@khan.acc.umu.se> <40453538.8050103@animezone.org> <20040303014115.GP19111@khan.acc.umu.se> From: Andi Kleen Date: 03 Mar 2004 03:39:26 +0100 In-Reply-To: <20040303014115.GP19111@khan.acc.umu.se.suse.lists.linux.kernel> Message-ID: Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2300 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs David Weinehall writes: > On Tue, Mar 02, 2004 at 08:30:32PM -0500, Andrew Ho wrote: > > XFS is the best filesystem. > > Well it'd better be, it's 10 times the size of ext3, 5 times the size of > ReiserFS and 3.5 times the size of JFS. I think your ext3 numbers are off, most likely you didn't include JBD. > And people say size doesn't matter. A lot of this is actually optional features the other FS don't have, like support for separate realtime volumes and compat code for old revisions, journaled quotas etc. I think you could relatively easily do a "mini xfs" that would be a lot smaller. But on today's machines it's not really an issue anymore. -Andi From owner-linux-xfs@oss.sgi.com Tue Mar 2 18:48:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Mar 2004 18:48:44 -0800 (PST) Received: from corpmail.outblaze.com (corpmail.outblaze.com [203.86.166.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i232mfKO010052 for ; Tue, 2 Mar 2004 18:48:42 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by corpmail.outblaze.com (Postfix) with ESMTP id 13A9E37AD1; Wed, 3 Mar 2004 02:48:40 +0000 (GMT) Received: from linuxmail.org (210-177-227-130.outblaze.com [210.177.227.130]) by corpmail.outblaze.com (Postfix) with ESMTP id 6F82216DD9F; Wed, 3 Mar 2004 02:48:39 +0000 (GMT) Message-ID: <40454787.9010901@linuxmail.org> Date: Wed, 03 Mar 2004 10:48:39 +0800 From: Feizhou User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: ext3-users@redhat.com, linux-xfs@oss.sgi.com Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 References: <4044119D.6050502@andrew.cmu.edu> <4044366B.3000405@namesys.com> <4044B787.7080301@andrew.cmu.edu> <1078266793.8582.24.camel@mentor.gurulabs.com> <20040302224758.GK19111@khan.acc.umu.se> <40453538.8050103@animezone.org> In-Reply-To: <40453538.8050103@animezone.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.11; VAE: 6.24.0.6; VDF: 6.24.0.35; host: corpmail.outblaze.com) X-archive-position: 2301 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: feizhou@linuxmail.org Precedence: bulk X-list: linux-xfs Andrew Ho wrote: > XFS is the best filesystem. Sorry, but saying/writing that does not make it so. Different filesystems have their strengths and weaknesses and those are also different under different circumstances. Where xfs may be fast given a number of factors, you will find that other filesystems will excel after a change or two in one or two of factors. eg: Large directory hash in a fileserver. You might find where nfs/smb clients = 8 then ext3 wins BIG time but where nfs/smb clients = 16 or higher, xfs excels and widens the gap with a ext3 based filesystem as the number of clients grows. There is no perfect filesystem. From owner-linux-xfs@oss.sgi.com Tue Mar 2 22:01:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Mar 2004 22:01:13 -0800 (PST) Received: from dewire.com ([212.28.208.94]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i23610KO020865 for ; Tue, 2 Mar 2004 22:01:01 -0800 Received: (qmail 13657 invoked from network); 3 Mar 2004 06:00:58 -0000 Received: from h6n2fls33o811.telia.com (HELO nisse.hemma.dewire.com) (217.208.98.6) by 212.28.208.94 with SMTP; 3 Mar 2004 06:00:58 -0000 From: Robin Rosenberg To: David Weinehall Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 Date: Wed, 3 Mar 2004 07:00:56 +0100 User-Agent: KMail/1.6.1 Cc: Andrew Ho , Dax Kelson , Peter Nelson , Hans Reiser , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com References: <4044119D.6050502@andrew.cmu.edu> <40453538.8050103@animezone.org> <20040303014115.GP19111@khan.acc.umu.se> In-Reply-To: <20040303014115.GP19111@khan.acc.umu.se> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403030700.57164.robin.rosenberg.lists@dewire.com> X-archive-position: 2302 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robin.rosenberg.lists@dewire.com Precedence: bulk X-list: linux-xfs On Wednesday 03 March 2004 02:41, David Weinehall wrote: > On Tue, Mar 02, 2004 at 08:30:32PM -0500, Andrew Ho wrote: > > XFS is the best filesystem. > > Well it'd better be, it's 10 times the size of ext3, 5 times the size of > ReiserFS and 3.5 times the size of JFS. > > And people say size doesn't matter. Recoverability matters to me. The driver could be 10 megabyte and *I* would not care. XFS seems to stand no matter how rudely the OS is knocked down. After a few hundred crashes (laptop, kids, drained batteries) I'd expect something bad to happen, but no. XFS returns my data quickly and happily everytime (as opposed to most of the time). Maybe the're a bit of luck. Salute to XFS! -- robin From owner-linux-xfs@oss.sgi.com Tue Mar 2 22:31:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Mar 2004 22:31:13 -0800 (PST) Received: from thebsh.namesys.com (thebsh.namesys.com [212.16.7.65]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i236V0KO022579 for ; Tue, 2 Mar 2004 22:31:01 -0800 Received: (qmail 29651 invoked from network); 3 Mar 2004 06:30:54 -0000 Received: from bitshadow.namesys.com (HELO namesys.com) (212.16.7.71) by thebsh.namesys.com with SMTP; 3 Mar 2004 06:30:54 -0000 Message-ID: <40457B9E.3060706@namesys.com> Date: Wed, 03 Mar 2004 09:30:54 +0300 From: Hans Reiser User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dax Kelson CC: Peter Nelson , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 References: <4044119D.6050502@andrew.cmu.edu> <4044366B.3000405@namesys.com> <4044B787.7080301@andrew.cmu.edu> <1078266793.8582.24.camel@mentor.gurulabs.com> In-Reply-To: <1078266793.8582.24.camel@mentor.gurulabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2303 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: reiser@namesys.com Precedence: bulk X-list: linux-xfs Unfortunately it is a bit more complex, and the truth is less complementary to us than what you write. Reiser4's CPU usage has come down a lot, but it still consumes more CPU than V3. It should consume less, and Zam is currently working on making writes more CPU efficient. As soon as I get funding from somewhere and can stop worrying about money, I will do a complete code review, and CPU usage will go way down. There are always lots of stupid little things that consume a lot of CPU that I find whenever I stop chasing money and review code. We are shipping because CPU usage is not as important as IO efficiency for a filesystem, and while Reiser4 is not as fast as it will be in 3-6 months, it is faster than anything else available so it should be shipped. Hans Dax Kelson wrote: >On Tue, 2004-03-02 at 09:34, Peter Nelson wrote: > > >>Hans Reiser wrote: >> >>I'm confused as to why performing a benchmark out of cache as opposed to >>on disk would hurt performance? >> >> > >My understanding (which could be completely wrong) is that reieserfs v3 >and v4 are algorithmically more complex than ext2 or ext3. Reiserfs >spends more CPU time to make the eventual ondisk operations more >efficient/faster. > >When operating purely or mostly out of ram, the higher CPU utilization >of reiserfs hurts performance compared to ext2 and ext3. > >When your system I/O utilization exceeds cache size and your disks >starting getting busy, the CPU time previously invested by reiserfs pays >big dividends and provides large performance gains versus more >simplistic filesystems. > >In other words, the CPU penalty paid by reiserfs v3/v4 is more than made >up for by the resultant more efficient disk operations. Reiserfs trades >CPU for disk performance. > >In a nutshell, if you have more memory than you know what do to with, >stick with ext3. If you spend all your time waiting for disk operations >to complete, go with reiserfs. > >Dax Kelson >Guru Labs > > > > > -- Hans From owner-linux-xfs@oss.sgi.com Tue Mar 2 23:48:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Mar 2004 23:48:38 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i237mEKO028424 for ; Tue, 2 Mar 2004 23:48:15 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AyR6i-0006jG-Dt; Wed, 03 Mar 2004 07:47:56 +0000 Date: Wed, 3 Mar 2004 07:47:56 +0000 From: Christoph Hellwig To: Andi Kleen Cc: David Weinehall , Dax Kelson , Peter Nelson , Hans Reiser , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 Message-ID: <20040303074756.A25861@infradead.org> Mail-Followup-To: Christoph Hellwig , Andi Kleen , David Weinehall , Dax Kelson , Peter Nelson , Hans Reiser , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com References: <4044119D.6050502@andrew.cmu.edu> <4044366B.3000405@namesys.com> <4044B787.7080301@andrew.cmu.edu> <1078266793.8582.24.camel@mentor.gurulabs.com> <20040302224758.GK19111@khan.acc.umu.se> <40453538.8050103@animezone.org> <20040303014115.GP19111@khan.acc.umu.se> <20040303014115.GP19111@khan.acc.umu.se.suse.lists.linux.kernel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ak@suse.de on Wed, Mar 03, 2004 at 03:39:26AM +0100 X-archive-position: 2304 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Wed, Mar 03, 2004 at 03:39:26AM +0100, Andi Kleen wrote: > A lot of this is actually optional features the other FS don't have, > like support for separate realtime volumes and compat code for old > revisions, journaled quotas etc. I think you could > relatively easily do a "mini xfs" that would be a lot smaller. And a whole lot of code to stay somewhat in sync with other codebases.. From owner-linux-xfs@oss.sgi.com Wed Mar 3 00:03:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 00:04:00 -0800 (PST) Received: from thebsh.namesys.com (thebsh.namesys.com [212.16.7.65]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2383iKO029590 for ; Wed, 3 Mar 2004 00:03:44 -0800 Received: (qmail 4325 invoked from network); 3 Mar 2004 08:03:37 -0000 Received: from bitshadow.namesys.com (HELO namesys.com) (212.16.7.71) by thebsh.namesys.com with SMTP; 3 Mar 2004 08:03:37 -0000 Message-ID: <40459159.1090501@namesys.com> Date: Wed, 03 Mar 2004 11:03:37 +0300 From: Hans Reiser User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: Andi Kleen , David Weinehall , Dax Kelson , Peter Nelson , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 References: <4044119D.6050502@andrew.cmu.edu> <4044366B.3000405@namesys.com> <4044B787.7080301@andrew.cmu.edu> <1078266793.8582.24.camel@mentor.gurulabs.com> <20040302224758.GK19111@khan.acc.umu.se> <40453538.8050103@animezone.org> <20040303014115.GP19111@khan.acc.umu.se> <20040303014115.GP19111@khan.acc.umu.se.suse.lists.linux.kernel> <20040303074756.A25861@infradead.org> In-Reply-To: <20040303074756.A25861@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2305 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: reiser@namesys.com Precedence: bulk X-list: linux-xfs Christoph Hellwig wrote: >On Wed, Mar 03, 2004 at 03:39:26AM +0100, Andi Kleen wrote: > > >>A lot of this is actually optional features the other FS don't have, >>like support for separate realtime volumes and compat code for old >>revisions, journaled quotas etc. I think you could >>relatively easily do a "mini xfs" that would be a lot smaller. >> >> > >And a whole lot of code to stay somewhat in sync with other codebases.. > > > > > What is significant is not the affect of code size on modern architectures, code size hurts developers as the code becomes very hard to make deep changes to. It is very important to carefully design your code to be easy to change. This is why we tossed the V3 code and wrote V4 from scratch using plugins at every conceivable abstraction layer. I think V4 will be our last rewrite from scratch because of our plugins, and because of how easy we find the code to work on now. I think XFS is going to stagnate over time based on the former developers who have told me how hard it is to work on the code. Christoph probably disagrees, and he knows the XFS code far better than I.;-) -- Hans From owner-linux-xfs@oss.sgi.com Wed Mar 3 00:16:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 00:17:02 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i238GMKO032443 for ; Wed, 3 Mar 2004 00:16:23 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i238GLb30114; Wed, 3 Mar 2004 03:16:21 -0500 Received: from [172.31.3.35] (arjanv.cipe.redhat.com [10.0.2.48]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i238GJ821745; Wed, 3 Mar 2004 03:16:19 -0500 Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 From: Arjan van de Ven Reply-To: arjanv@redhat.com To: Hans Reiser Cc: Christoph Hellwig , Andi Kleen , David Weinehall , Dax Kelson , Peter Nelson , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com In-Reply-To: <40459159.1090501@namesys.com> References: <4044119D.6050502@andrew.cmu.edu> <4044366B.3000405@namesys.com> <4044B787.7080301@andrew.cmu.edu> <1078266793.8582.24.camel@mentor.gurulabs.com> <20040302224758.GK19111@khan.acc.umu.se> <40453538.8050103@animezone.org> <20040303014115.GP19111@khan.acc.umu.se> <20040303014115.GP19111@khan.acc.umu.se.suse.lists.linux.kernel> <20040303074756.A25861@infradead.org> <40459159.1090501@namesys.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-UIWviqtVZ667IOZUDxJi" Organization: Red Hat, Inc. Message-Id: <1078301777.4446.5.camel@laptop.fenrus.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 03 Mar 2004 09:16:18 +0100 X-archive-position: 2306 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: arjanv@redhat.com Precedence: bulk X-list: linux-xfs --=-UIWviqtVZ667IOZUDxJi Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2004-03-03 at 09:03, Hans Reiser wrote: > I=20 > think V4 will be our last rewrite from scratch because of our plugins,=20 > and because of how easy we find the code to work on now. can we quote you on that 3 years from now ? ;-) --=-UIWviqtVZ667IOZUDxJi Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQBARZRRxULwo51rQBIRApyLAKCZmezwjn5trHZy/2JbIIpAD1Qk7ACfbSdV x8BHDOQqYw1Q3yzAcD9d2As= =3j8W -----END PGP SIGNATURE----- --=-UIWviqtVZ667IOZUDxJi-- From owner-linux-xfs@oss.sgi.com Wed Mar 3 01:35:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 01:35:46 -0800 (PST) Received: from thebsh.namesys.com (thebsh.namesys.com [212.16.7.65]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i239ZIKO010962 for ; Wed, 3 Mar 2004 01:35:19 -0800 Received: (qmail 11955 invoked from network); 3 Mar 2004 09:35:12 -0000 Received: from bitshadow.namesys.com (HELO namesys.com) (212.16.7.71) by thebsh.namesys.com with SMTP; 3 Mar 2004 09:35:12 -0000 Message-ID: <4045A6D0.6050203@namesys.com> Date: Wed, 03 Mar 2004 12:35:12 +0300 From: Hans Reiser User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: arjanv@redhat.com CC: Christoph Hellwig , Andi Kleen , David Weinehall , Dax Kelson , Peter Nelson , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 References: <4044119D.6050502@andrew.cmu.edu> <4044366B.3000405@namesys.com> <4044B787.7080301@andrew.cmu.edu> <1078266793.8582.24.camel@mentor.gurulabs.com> <20040302224758.GK19111@khan.acc.umu.se> <40453538.8050103@animezone.org> <20040303014115.GP19111@khan.acc.umu.se> <20040303014115.GP19111@khan.acc.umu.se.suse.lists.linux.kernel> <20040303074756.A25861@infradead.org> <40459159.1090501@namesys.com> <1078301777.4446.5.camel@laptop.fenrus.com> In-Reply-To: <1078301777.4446.5.camel@laptop.fenrus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2307 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: reiser@namesys.com Precedence: bulk X-list: linux-xfs Arjan van de Ven wrote: >On Wed, 2004-03-03 at 09:03, Hans Reiser wrote: > > >> I >>think V4 will be our last rewrite from scratch because of our plugins, >>and because of how easy we find the code to work on now. >> >> > >can we quote you on that 3 years from now ? ;-) > > Yes, I think so. We are going to add a nice little optimization for compiles to Reiser4 as a result of thinking about compile benchmarks. We are going to sort filenames (and their corresponding file bodies) whose penultimate character is . by their last character first. It seems this is optimal, and it is simple, and it is without any real world drawbacks. This is easy for us because of our plugin design. -- Hans From owner-linux-xfs@oss.sgi.com Wed Mar 3 01:44:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 01:45:01 -0800 (PST) Received: from kerberos.felipe-alfaro.com (153.Red-213-4-13.pooles.rima-tde.net [213.4.13.153]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i239iPKO012002 for ; Wed, 3 Mar 2004 01:44:34 -0800 Received: from [192.168.0.100] (teapot.felipe-alfaro.com [192.168.0.100]) by kerberos.felipe-alfaro.com (Postfix) with ESMTP id 5CDC242EAE; Wed, 3 Mar 2004 10:44:06 +0100 (CET) Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 From: Felipe Alfaro Solana To: Robin Rosenberg Cc: David Weinehall , Andrew Ho , Dax Kelson , Peter Nelson , Hans Reiser , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com In-Reply-To: <200403030700.57164.robin.rosenberg.lists@dewire.com> References: <4044119D.6050502@andrew.cmu.edu> <40453538.8050103@animezone.org> <20040303014115.GP19111@khan.acc.umu.se> <200403030700.57164.robin.rosenberg.lists@dewire.com> Content-Type: text/plain Message-Id: <1078307033.904.1.camel@teapot.felipe-alfaro.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-8) Date: Wed, 03 Mar 2004 10:43:53 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 2308 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: felipe_alfaro@linuxmail.org Precedence: bulk X-list: linux-xfs On Wed, 2004-03-03 at 07:00, Robin Rosenberg wrote: > On Wednesday 03 March 2004 02:41, David Weinehall wrote: > > On Tue, Mar 02, 2004 at 08:30:32PM -0500, Andrew Ho wrote: > > > XFS is the best filesystem. > > > > Well it'd better be, it's 10 times the size of ext3, 5 times the size of > > ReiserFS and 3.5 times the size of JFS. > > > > And people say size doesn't matter. > > Recoverability matters to me. The driver could be 10 megabyte and > *I* would not care. XFS seems to stand no matter how rudely the OS > is knocked down. But XFS easily breaks down due to media defects. Once ago I used XFS, but I lost all data on one of my volumes due to a bad block on my hard disk. XFS was unable to recover from the error, and the XFS recovery tools were unable to deal with the error. From owner-linux-xfs@oss.sgi.com Wed Mar 3 01:59:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 01:59:55 -0800 (PST) Received: from dewire.com ([212.28.208.94]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i239xTKO013633 for ; Wed, 3 Mar 2004 01:59:30 -0800 Received: (qmail 15836 invoked from network); 3 Mar 2004 09:59:27 -0000 Received: from unknown (HELO ?10.1.1.134?) (10.1.1.134) by 212.28.208.94 with SMTP; 3 Mar 2004 09:59:27 -0000 From: Robin Rosenberg To: Felipe Alfaro Solana Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 Date: Wed, 3 Mar 2004 10:59:26 +0100 User-Agent: KMail/1.6.1 Cc: David Weinehall , Andrew Ho , Dax Kelson , Peter Nelson , Hans Reiser , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com References: <4044119D.6050502@andrew.cmu.edu> <200403030700.57164.robin.rosenberg.lists@dewire.com> <1078307033.904.1.camel@teapot.felipe-alfaro.com> In-Reply-To: <1078307033.904.1.camel@teapot.felipe-alfaro.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403031059.26483.robin.rosenberg.lists@dewire.com> X-archive-position: 2309 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robin.rosenberg.lists@dewire.com Precedence: bulk X-list: linux-xfs On Wednesday 03 March 2004 10:43, Felipe Alfaro Solana wrote: > But XFS easily breaks down due to media defects. Once ago I used XFS, > but I lost all data on one of my volumes due to a bad block on my hard > disk. XFS was unable to recover from the error, and the XFS recovery > tools were unable to deal with the error. What file systems work on defect media? As for crashed disks I rarely bothered trying to "fix" them anymore. I save what I can and restore what's backed up and recovery tools (other than the undo-delete ones) usually destroy what's left, but that's not unique to XFS. Depending on how good my backups are I sometimes try the recovery tools just to see, but that has never helped so far. -- robin From owner-linux-xfs@oss.sgi.com Wed Mar 3 02:09:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 02:10:03 -0800 (PST) Received: from goliath.sylaba.poznan.pl (goliath.sylaba.poznan.pl [213.17.226.43]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i23A9nKO014762 for ; Wed, 3 Mar 2004 02:09:50 -0800 Received: by goliath.sylaba.poznan.pl (Postfix, from userid 1003) id 72FFD95741; Wed, 3 Mar 2004 11:09:45 +0100 (CET) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by goliath.sylaba.poznan.pl (Postfix) with ESMTP id 8AF799571E; Wed, 3 Mar 2004 11:09:44 +0100 (CET) Received: from [192.168.1.10] (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.12.10/8.12.10) with ESMTP id i23ADIYm002992; Wed, 3 Mar 2004 11:13:18 +0100 Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Felipe Alfaro Solana Cc: Robin Rosenberg , David Weinehall , Andrew Ho , Dax Kelson , Peter Nelson , Hans Reiser , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com In-Reply-To: <1078307033.904.1.camel@teapot.felipe-alfaro.com> References: <4044119D.6050502@andrew.cmu.edu> <40453538.8050103@animezone.org> <20040303014115.GP19111@khan.acc.umu.se> <200403030700.57164.robin.rosenberg.lists@dewire.com> <1078307033.904.1.camel@teapot.felipe-alfaro.com> Content-Type: text/plain Message-Id: <1078308797.2641.14.camel@venus.local.navi.pl> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 03 Mar 2004 11:13:18 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 2310 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: linux-xfs On Wed, 2004-03-03 at 10:43, Felipe Alfaro Solana wrote: > On Wed, 2004-03-03 at 07:00, Robin Rosenberg wrote: > > On Wednesday 03 March 2004 02:41, David Weinehall wrote: > > > On Tue, Mar 02, 2004 at 08:30:32PM -0500, Andrew Ho wrote: > > > > XFS is the best filesystem. > > > > > > Well it'd better be, it's 10 times the size of ext3, 5 times the size of > > > ReiserFS and 3.5 times the size of JFS. > > > > > > And people say size doesn't matter. > > > > Recoverability matters to me. The driver could be 10 megabyte and > > *I* would not care. XFS seems to stand no matter how rudely the OS > > is knocked down. > > But XFS easily breaks down due to media defects. Once ago I used XFS, > but I lost all data on one of my volumes due to a bad block on my hard > disk. XFS was unable to recover from the error, and the XFS recovery > tools were unable to deal with the error. You lost all data? Or you just had to restore them from backup? If you didn't have a backup it is your fault not XFS one :) But even if you had no backup, why didn't you move your data (using dd or something else) to another (without defects) drive, and run recovery on new drive? Regards, Olaf From owner-linux-xfs@oss.sgi.com Wed Mar 3 02:19:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 02:19:48 -0800 (PST) Received: from kerberos.felipe-alfaro.com (153.Red-213-4-13.pooles.rima-tde.net [213.4.13.153]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i23AJYKO016491 for ; Wed, 3 Mar 2004 02:19:35 -0800 Received: from [192.168.0.100] (teapot.felipe-alfaro.com [192.168.0.100]) by kerberos.felipe-alfaro.com (Postfix) with ESMTP id 208E142EAE; Wed, 3 Mar 2004 11:19:13 +0100 (CET) Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 From: Felipe Alfaro Solana To: Robin Rosenberg Cc: David Weinehall , Andrew Ho , Dax Kelson , Peter Nelson , Hans Reiser , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com In-Reply-To: <200403031059.26483.robin.rosenberg.lists@dewire.com> References: <4044119D.6050502@andrew.cmu.edu> <200403030700.57164.robin.rosenberg.lists@dewire.com> <1078307033.904.1.camel@teapot.felipe-alfaro.com> <200403031059.26483.robin.rosenberg.lists@dewire.com> Content-Type: text/plain Message-Id: <1078309141.863.3.camel@teapot.felipe-alfaro.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-8) Date: Wed, 03 Mar 2004 11:19:01 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 2311 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: felipe_alfaro@linuxmail.org Precedence: bulk X-list: linux-xfs On Wed, 2004-03-03 at 10:59, Robin Rosenberg wrote: > On Wednesday 03 March 2004 10:43, Felipe Alfaro Solana wrote: > > But XFS easily breaks down due to media defects. Once ago I used XFS, > > but I lost all data on one of my volumes due to a bad block on my hard > > disk. XFS was unable to recover from the error, and the XFS recovery > > tools were unable to deal with the error. > > What file systems work on defect media? It's not a matter of working: it's a matter of recovering. A bad disk block could potentially destroy a file or a directory, but shouldn't make a filesystem not mountable nor recoverable. > As for crashed disks I rarely bothered trying to "fix" them anymore. I save > what I can and restore what's backed up and recovery tools (other than > the undo-delete ones) usually destroy what's left, but that's not unique to > XFS. Depending on how good my backups are I sometimes try the recovery > tools just to see, but that has never helped so far. The problem is that I couldn't save anything: the XFS volume refused to mount and the XFS recovery tools refused to fix anything. It was just a single disk bad block. For example in ext2/3 critical parts are replicated several times over the volume, so there's minimal chance of being unable to mount the volume and recover important files. From owner-linux-xfs@oss.sgi.com Wed Mar 3 02:25:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 02:25:28 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i23APFKO017526 for ; Wed, 3 Mar 2004 02:25:15 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i23APA02005414 for ; Wed, 3 Mar 2004 02:25:10 -0800 Received: from gollum (shiva215.melbourne.sgi.com [134.14.52.215]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with SMTP id i23AOHVF34884743; Wed, 3 Mar 2004 04:24:34 -0600 (CST) From: "Mike Gigante" To: "Robin Rosenberg" , "Felipe Alfaro Solana" Cc: "David Weinehall" , "Andrew Ho" , "Dax Kelson" , "Peter Nelson" , "Hans Reiser" , "linux-kernel" , , , , , Subject: RE: Desktop Filesystem Benchmarks in 2.6.3 Date: Wed, 3 Mar 2004 21:24:10 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200403031059.26483.robin.rosenberg.lists@dewire.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-archive-position: 2312 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mg@sgi.com Precedence: bulk X-list: linux-xfs On Wednesday 03 March 2004 10:43, Felipe Alfaro Solana wrote: > But XFS easily breaks down due to media defects. Once ago I used XFS, > but I lost all data on one of my volumes due to a bad block on my hard > disk. XFS was unable to recover from the error, and the XFS recovery > tools were unable to deal with the error. A single bad-block rendered the entire filesystem non-recoverable for XFS? Sounds difficult to believe since there is redundancy such as multiple copies of the superblock etc. I can believe you lost *some* data, but "lost all my data"??? -- I believe that you'd have to had had *considerably* more than "a bad block" :-) Mike From owner-linux-xfs@oss.sgi.com Wed Mar 3 05:07:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 05:07:55 -0800 (PST) Received: from kerberos.felipe-alfaro.com (153.Red-213-4-13.pooles.rima-tde.net [213.4.13.153]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i23D7iKO020004 for ; Wed, 3 Mar 2004 05:07:48 -0800 Received: from [192.168.0.100] (teapot.felipe-alfaro.com [192.168.0.100]) by kerberos.felipe-alfaro.com (Postfix) with ESMTP id 20F1C42E2A; Wed, 3 Mar 2004 14:07:28 +0100 (CET) Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 From: Felipe Alfaro Solana To: Olaf =?iso-8859-2?Q?Fr=B1czyk?= Cc: Robin Rosenberg , David Weinehall , Andrew Ho , Dax Kelson , Peter Nelson , Hans Reiser , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com In-Reply-To: <1078308797.2641.14.camel@venus.local.navi.pl> References: <4044119D.6050502@andrew.cmu.edu> <40453538.8050103@animezone.org> <20040303014115.GP19111@khan.acc.umu.se> <200403030700.57164.robin.rosenberg.lists@dewire.com> <1078307033.904.1.camel@teapot.felipe-alfaro.com> <1078308797.2641.14.camel@venus.local.navi.pl> Content-Type: text/plain; charset=UTF-8 Message-Id: <1078319235.1113.2.camel@teapot.felipe-alfaro.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-8) Date: Wed, 03 Mar 2004 14:07:16 +0100 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i23D7pKO020016 X-archive-position: 2313 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: felipe_alfaro@linuxmail.org Precedence: bulk X-list: linux-xfs On Wed, 2004-03-03 at 11:13, Olaf FrÄ…czyk wrote: > > > Recoverability matters to me. The driver could be 10 megabyte and > > > *I* would not care. XFS seems to stand no matter how rudely the OS > > > is knocked down. > > But XFS easily breaks down due to media defects. Once ago I used XFS, > > but I lost all data on one of my volumes due to a bad block on my hard > > disk. XFS was unable to recover from the error, and the XFS recovery > > tools were unable to deal with the error. > You lost all data? Or you just had to restore them from backup? If you > didn't have a backup it is your fault not XFS one :) Well, it was a testing machine with no important data, so I could just afford to lose everything, as it was the case. > But even if you had no backup, why didn't you move your data (using dd > or something else) to another (without defects) drive, and run recovery > on new drive? I tried, but it proved more difficult than expected, since the computer was a laptop and I couldn't move the HDD to another computer. Using the distro rescue CD was useless as it's kernel didn't have XFS support. All in all, XFS recovery was a nightmare compared to ext3 recovery, for example. From owner-linux-xfs@oss.sgi.com Wed Mar 3 05:14:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 05:15:08 -0800 (PST) Received: from kerberos.felipe-alfaro.com (153.Red-213-4-13.pooles.rima-tde.net [213.4.13.153]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i23DEgKO021193 for ; Wed, 3 Mar 2004 05:14:45 -0800 Received: from [192.168.0.100] (teapot.felipe-alfaro.com [192.168.0.100]) by kerberos.felipe-alfaro.com (Postfix) with ESMTP id 6C3A042E2A; Wed, 3 Mar 2004 14:14:29 +0100 (CET) Subject: RE: Desktop Filesystem Benchmarks in 2.6.3 From: Felipe Alfaro Solana To: Mike Gigante Cc: Robin Rosenberg , David Weinehall , Andrew Ho , Dax Kelson , Peter Nelson , Hans Reiser , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1078319654.1113.10.camel@teapot.felipe-alfaro.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-8) Date: Wed, 03 Mar 2004 14:14:16 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 2314 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: felipe_alfaro@linuxmail.org Precedence: bulk X-list: linux-xfs On Wed, 2004-03-03 at 11:24, Mike Gigante wrote: > On Wednesday 03 March 2004 10:43, Felipe Alfaro Solana wrote: > > But XFS easily breaks down due to media defects. Once ago I used XFS, > > but I lost all data on one of my volumes due to a bad block on my hard > > disk. XFS was unable to recover from the error, and the XFS recovery > > tools were unable to deal with the error. > > A single bad-block rendered the entire filesystem non-recoverable > for XFS? Sounds difficult to believe since there is redundancy such > as multiple copies of the superblock etc. You should believe it... It was a combination of a power failure and some bad disk sectors. Maybe it was just a kernel bug, after all, as this happened with 2.5 kernels: during kernel bootup, the kernel invoked XFS recovery but it failed due to media errors. > I can believe you lost *some* data, but "lost all my data"??? -- I > believe that you'd have to had had *considerably* more than > "a bad block" :-) It was exactly one disk block, at least that's what the low-level HDD diagnostic program for my IBM/Hitachi laptop drive told me. In fact, the HDD diagnostic was able to recover the media defects. That could have been one of those very improbable cases, but I lost the entire volume. Neither the kernel nor XFS tools were able to recover the XFS volume. However, I must say that I didn't try every single known way of performing the recovery, but recovery with ext2/3 is pretty straightforward. As I said, it could have been a kernel bug, or maybe I simply didn't understand the implications of recovery, but xfs_repair was totally unable to fix the problem. It instructed me to use "dd" to move the volume to a healthy disk and retry the operation, but it was not easy to do that as I explained before. From owner-linux-xfs@oss.sgi.com Wed Mar 3 05:29:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 05:30:07 -0800 (PST) Received: from fgiht-19 (fgiht-19.e-technik.tu-ilmenau.de [141.24.129.4]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i23DTaKP023800 for ; Wed, 3 Mar 2004 05:29:36 -0800 Date: Wed, 03 Mar 2004 14:29:35 +0100 To: linux-xfs@oss.sgi.com Subject: E-mail account security warning. From: support@sgi.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------xxnlhmxorpxxohdjvlmq" X-archive-position: 2315 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: support@sgi.com Precedence: bulk X-list: linux-xfs ----------xxnlhmxorpxxohdjvlmq Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear user of e-mail server "Sgi.com", We warn you about some attacks on your e-mail account. Your computer may contain viruses, in order to keep your computer and e-mail account safe, please, follow the instructions. Please, read the attach for further details. Kind regards, The Sgi.com team http://www.sgi.com ----------xxnlhmxorpxxohdjvlmq Content-Type: application/octet-stream; name="Readme.pif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Readme.pif" TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAkAAAACfJ7VtjqIMIY6iDCGOogwhjqIMIYKiDCO23 kAgNqIMIn4iRCGKogwikroUIYqiDCFJpY2hjqIMIAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAUEUAAEwBAwDUi0VAAAAAAAAAAADgAA8BCwEFDAAwAAAAEAAA AKAAADDVAAAAsAAAAOAAAAAAQAAAEAAAAAIAAAQAAAAAAAAABAAAAAAAAAAA 8AAAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACk4wAAWAIAAADgAACkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABVUFgwAAAAAACgAAAA EAAAAAAAAAACAAAAAAAAAAAAAAAAAACAAADgVVBYMQAAAAAAMAAAALAAAAAo AAAAAgAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADgAAAABgAAACoA AAAAAAAAAAAAAAAAAEAAAMAxLjI0AFVQWCEMCQII6ACvqtAfIwK+tgAACyUA AABWAAAmAACt2+3//1WL7FeNPRBxQACLRQiJB8cFqmEKAQAAg78jm/vHBPcl rgwU/4E9GnACzX73L3XjX8nCBAA6g8T8VldTP3/O3JcfD4LBQC9xCmgFEe6b b28G6JD/AMdF/ACL94sGJQd3/9/9gIteBIHjF38Lw4vI0eiL1oHCNAYfGjPD 7tv//4PhAQvJdAU137AImYkGg8YE/zuBffzjPoHkV8h1wXT8//9IINvIbwLX ZzD+7J1NAaOhCv3B4AID8Gd/+990i9jB6Asz2IvDDwclgFYsnQsP/m/HdozG 7wvoElEz0vd1CIvCW19e/b99ECdX/It9EE0MwekCM8DjAvOr2xu6zQt2Awmq SggAU1YyM+/b//bbZovQPhCKHgPTgfrx/1F8BoHqB7ft5+8Dwj0GfAUtRuLd cBArwl7/7u7fW8NaU4tdDF1qGeizN4PAYfyqS3UGObDY8VtXHwkwdW3DQsJT /60cMbv/yLYm2AkQA9iDwxBTakAMMIL7g22FiTgXDCSKC8B0M8YIs7kgXysM Ggz87bDP3AZACjD6UwiLPzvbNtjrCgyI/1t5DDW+bfe9agBqARWgVA5QDVAM 3AwjYewEL+xhNcJCuzVVfaVNEEQtrAV/G3v3COIHBEND6wsMAwgCrElRagT4 5v/tWVHB3IrQgOI/wegG4vNZAxWSq5L+B3vpAYMSdQ9PUGa4DQpmq1hZdyj8 F/91rovLK/mwPZC1oJe3v32A+j5zFwQzdw2AwkEHWnYDBut327+1DgTLCYDq PsDiAgorZuLWw4Ps2mDLAb+5MXiL+GQftlWsEhlSCMv4jVX4QnuxbzaPAsdC BNAjNjSevbFtAvguFH4uVo2FL/vdE8cGKcdGMI1F+CsNozGwAjGYaZLDvq8X TgjxZRIAm50tlolZAoohYJfNDty2Wxgy3/W/jCTIusTT4vHjFTCL2sHiBcMc 2//B6xsL0w+2GEADFu71/1UIRtNFDDRQQ7Smhcm2XQEZCMDSAS3teNv38T0C ReGDOJUUtO8OtiwILlqJ3xCPAOstHBQufHMb4NCLCDv3dQb5rAXsPx2LQATr 6FItwy63PghbHUA8gcTU/gdXx/4aXN2F2AYo0AUCLBaJhd33HvsZjRhQ/7UM F6ZmRPvbUum/RWDqq9dHg8n/8q5SJcl2GGf89wsu4LKnbPsCdIA/sNVFrOu4 DPcotUbDRmUdDBjG+3sE0WpkINDr8sLb32s/XMr8UJ9oYhV4CCMQdcO3y8nD 6x3z0eK5CZrR6nMP3P6/CfIgg7jt4vSJFIUQmCpAPaRynRYavtxdVkL3H3UY 2McCd0HqCDIb/ysEKowYbeszwjHoH9SWLtiFwquaMsIeL761QWghmIpIyzUQ nEDBPfb+hgXqowlKAwUUCrRu6b19uQWECGvhQKMOWxgt7xBekhgJ+w0MwBcK 7oHh/zxJ48GD8QH67rXWFOEyYGQwBgZYMkXtX4FDGVZ1a3hWNBIJk/vKmxSJ Z0UjRJAU92T9swVYBzWsCsB19V4dz9IzyuiYBn/U8I1nLdb7ffbrF2h58HI4 T9nSl6Wq/fDwCnLjVPYzhcJnD+shrCSIReuDlOwJ3JbsAQXrUA4w9DoiK/A4 2dSiK7MSyVgiGGEZqYFJh54Y/wjNyPNvFDS3gwMM+P8MBnO/PbKA+AB0JIoR Wv97OtjCJakD64EUXQvNdzvwGvBQlVJm+vB2W3qDZlG8B2Z2CQxN8gfXbN/+ 4QVmC032A9FmiRAhCPgcZPAmTQv6GCiFYXD69GgAIEgUPGYv65X0EGEwypT6 ZGPFKUUIvHUC6xODl933VRX0QwW89OvPGBK2hQ1GjfTjsQtrYoAe23uELbtn L74DA2gHNi/+lUAPEw4b5ITtAQIgQEXPwtN8IPjMHhzOAZNlkO1fahYKuC6K 3TcoC3AUHoNN1AEEkr27DYkBG0KAxzlLAwRmbLffvgeQCgBmGJBmj0XSONpQ PNhruqb7B9UU2JYH2pjl/N62PQgjPNwCmucPMEyOLcu24AKe5KJwCIO2UmvR ERsSzWZmK7St2xToA6YsgEIIAizMDm0eONG68viGOTeLEyOgE0NwPMZKF3lV dOyQh7+amXfrOKL0hInYYdvDovQyHEz0GdluDbNMiwFJ68iG7KE1l23I+4oB Ao5jAc6NQjcFrlEOsCDXJTvMokeiui7PQsDOOkWSHlKrTMs8m8u4BQbAAcCd EGxrWyora/vETt6Bl+yhTrJfD1QohvsHQ6xDf3RAFigUXBBosl4/NDS8aO6A u7Roga6BT8QexVAKtGgv9MBgg4W/zAeuwAbs77dDaB1gP7pSjCEDNj7AqPw3 aO0cRZGrPAPDD7dIBkn7AoYLAbgoIAaL04tSFJ/U3WDT9QX4D8NcU1dokAtj 5LgLANDdwMaYqbukEjP8AQRKLgYdTASgLkzS1J1QqR+ETJoVE1+hvyurCgtc i3gUA3jVFuKwwb4INypXPsoHxT7Zab40VMpo3AWTbAX7HzkFi/hoyAAOf/fC Iw2X95r8T3XcnZx0kh5fW8HMU75AZKMIg/R8M/Q85NvZB34X7GjgYTD6mzsh l/BogIAM8PsigzzE9LfwAulw+URwL/hoHO3LsAPp2S0LgPQF1m7mPuxQE7po 5WYNZw0uuBcwIUF1LIs2WXPLAGLvHTZV2gllPzspivRhCJvrGpGZhd0sG5GF wL2asE4yZbz0dH0bQgZhO/gPZegCSRhGYU/SAOa7h9DtNVCLMNHgcaP0rYsU iS9KpiQkbrKZrD7eMV4S/aP4CQhTYSxJk0lRtohdg/QdBpRLB1sP0E0WTgZQ ahBJ4Ad+NncK4NUH4gTmGQAGgTTbYSnWDNDgQ138z9gv8oP4AXUE6gO3/RiT 0MO1VqI6i/C7OehFCDVaQ8M4U0Iocki0Ezm8AzKAULfEaNe6CtKsDYitXpkK w3K322pQ0PAfaASHRc8me40wYaEO+h2GnXvsvkPLEF4ECtIQJL/7/y7EBDSB OC11cGR0GwdkZWx0CUB97F7igHgDIenrDx0Oh6sWa77Ziwk2Uc8AUU7NCWsh aSMv+CadZi8lASdJ3xtk652l3sMcEJxMONh3OgHDaNAH/evmlAV3Ymt5AFOC 3Tplj054DfhoGxCpA3bjMUjgdRsPQoUzgY3dlv8MBgSLixgMwcFqRkdKToNK NQ3WlyUMQmYHPKO3zO0A6xIyDTlXGsCc1NX0QYUQK7PxCBn4xJ7rko3zAY5U jwok5pt0BxIK/HdgzeqHa5BhewKwlnqyNQ+MgBCSFBCn394PvxKB+0p2B7kG LYvL4zG3wW5sRVHCgFC4Wt1+HngNsNAr2DoMylAZi7LEJi1SEFAY85fQb1sB vGaF2w+UwJf8ITeQ7VMr22cYpcjULl02VTDPFDgS8ZLNLjezAV0iXsNt+2fR A5Q7RRByYwRhdLxfPRjssGL0H+/ibC0Dgwtleb9C+3sl6Ca+6WqXSYlmwVo+ EW2FR7Ixg4y9w3gENXgMybtPHP6Aff4gdQu4dHPrDBAtdCaJ7gChDYCH8O08 dDs6agaGAvRsr/UkXa5gwEHw8AIAFhq1cL/tljcM2X47WgWw6x8KdQoFCGeD UHoE6yUcMG5DFLHnG3vORFNZPAgKWicjtDZxCwzsUX4h2spsKs52BIbEZm3Z kI3K8qaf7I4PRoqIg/v/KdvrZmussBkGMLKAVEwNh8xtZFRGROwQdR382WQo KqoqkYsVBEGBAB1vw/r0L3MTI0ZWtvDYh/LrBlG467oLyAvEkwSvd7uSgbVq n2IsqQh+4wtABLD0IBKHH90iDtlqGUdlCFbiFpAlgASUNQDtG4nHtghooVn4 cRIp5368hxBfAUFtaAizGfBOudyib0BJGdxI93tTFqiTrQaWfSNxhMEH+DaT Xv9XSzCQ4L9GYVM9E7FXCZrd6x4Ncby1m/VowCcJdAQUXb+WmADkATISL+CA JIMtEgQGzFbc7H74GrkAkeuCviPAuQrtvkNXz8ZhEu46AzUJsbviBRQMJFkW ZG6N54OClFcxBTX8BtkaJCXoaZTGy5a7lYADha4NVgivlyzMMFZgCIWVhSS5 nBeBSwWG+MUlZQQHdgNzSLElnQzdWGf2s2Nf74C9bXYJCAtyBekWXBah7hjv UwCOWG25xVbyHSZbN//xh2ApFHPDOwUEu29h1hJ0XWm9GbhMAKuT9d6PoSur avAvpGbxsyVmkU8NCAMPhYrJIWsnpgQB74YC/FayXASoGP+1RECG7EJDElwv i2m9MHzXjAbMsNDIG/ce+nZoYMEcEuwjdg4DEjICGsosFFqa0KAsyIZrfL92 DJjIbJE4W1qkctC3rC28l4O9GFEvUiN4h70W1gYktVPs2FgEYR4BV+uqGPZB aJGJV3URaCPQQqTZQjKoO3YW4cDOKB/uxT5gsShwBEJQEmFuhzAIsgo77AAh uCn5TOgD0BtqjY2MAaB6tWbLHiY0OmrNFgRr4iS52LRAwbBI9lppJCbXVjbh PescGDIdncBsMLw2WOK90rCPIt4jlBP9Ag9qXbiBFExeB3YN8Bz/Bc2NmMhQ +sZAuUADYIq5Ya4K3zGzs81qWR/q/BHrX2J7KuWNZ4A+Q3UagH4dPNlWvBRm g370DUUVCutss2RfPQivU3sNxJPB7JMYaEgCZ3uTLJpA+BBq+CDEyweI0m91 FWwMbJmBpCwlCzTsNmAUixKAEPRQ/2AGq2EnBjgH7NhEsgcgDNtS9ALm7rcu EvYMZsFN9ggK+AEAws1m0PgI4y3Lm8hBybpKztew7P+/wS78F4vfK9qAf/8u dQFLiV3wUVI2JBpkOQHwWS6fFLM2HxG+WYXJ8uwC2HW4MIXuD+4hA7JNAh3u Ac9GS0jx/3y5pg+huzVphs1RTRJaCyDFoVmY5yqLncSZoUxOR/z/ZoL1BhJX Fic2WnT2U2oMk3oU9ixYJL8XOuvLPMGiTWASVN0INewDDHRsVxqGBbsswfxW PIE9oBnOlylAoj2bxStjJByww1SET0XQdwpT6cfMcOgbRAQqcdsgwwQR/G38 D4mF+nasqEccJD9mfKx+94N19APwTVZSLl7rIAof/jfMCprtfRAD+FnjA/zz pECX2hbxqj2qGIvGqK3ahgpsLoIQLrxl1FmRRS+LLEl6ny+gEJBYLYWFowAN wfKSgZEb2GQZ+A5NQsgNwSOd4z1wVFtClxasS/e2TTbH/NBOBggEAveuVX/q RgIPxXMPt15EllqIf7r44PyCi/CtPWcBO2QNPQkHUBtQreMojBV6Zq1a8iMG g/tDtl0e6ykQZidmWmY7VfJfhHCtUYYFGRQ8xZIeS3WwrIeI0PUDqfP8gD0z CACyNtW7K8YFCEkZvpMW6SFVlBouxgzLOutwG49HWD1CI6NMrQNqUyfjNQMb pQNylg4BoUL4qZGGITYbxmkMfy32M//rLulkC5G5GUEQPfpsRoUWAmoPoJnr G+OkodAZ9oKsXnAX/h38PTIyMEeF4xKg9IHGaIRih2wx8kjYIB/d3k5ixvQM CpMM4SBInE/PhBxgY5I1f9gw1wTDWE5ADOxKrrBCTzwSlL0gewxoX5T9AFHk guTn6gAIaHCrA+lKrV/mfwd7BZJ/cD4zNc7HjI00c12UK/iPx2AFcjH0wy1I NtYCmXbT8JiwAewN0ibrz1sQmi0MbpABR1PwZP1NiuQHD4vHWzYwgUar2GiR K30vC4eEH0BQSrJYDNbYk7ESVpsjl1ZEXsRL8JodUxcWZytgtmH0RQgr2IEP EMzBLEjRQhIQYNBkGVMUa1XX1oI2LRsCF+wEhm7VOUtvFWkeuAR+i1sI6+U6 UzsQtFDgrKdQESEQLcDkgiiFdRbw/9+AOuuJGusHUYsJiVkIWYkZWIPArKZD KrpOAzpQIASFd3GJe2UYj0MMC34IYOL1kBEKo6eebM+VFsvHrQUACY+VcLuD uwUEv5MNkBKFrYNT/Ktr8lHYOgEzd+jtnJ4OMBuHphmPsiHRaRh20hl2wa41 tEIGIk0o6FAjiZ6Dli9VyFpwWDbgE2lP8CIZ4PQEZvSweA84+zPpwbAb5cbe lMNzUDjR7MN2ZIoKJxvArNunnouwbQdfCP92/zGPFXEEBXFhWZb4DPQIXQRR BM8mm3ouuFcibrMZBvjzJr8g9RjBui/FHjcEA09/6x8IK7NAIYEHyVb0mPiB tSRYCw+PY/2w0rISFrEkq2gJP5yDPdIFcgrb4xBrtlUEJRnZSveqQaIbMH4+ CD+o/eFaUmeNQwhQAzMhaSPBxrH/Q4M7cBVXU6zVkuBo6TJWd51vDEIETVbs 3k5O3/3/9rEB/TtNcjSsPDByBDw5diQ8QQdadhw8YfCXLjV6+Twu1TxfdAw8 LdvCBaAFsQsKYQc4Q75hYPiKyOvH/JHFTfzmCGTXTEtzMwqWAtaVBkrISbMM dUa8YPoCfAmSCMjXQTIjdWouIwiu6GZxFOssdwKuYkWyBTDtAV6cfARz9Ika 4dsGORGt+Kn4D4Oj8xE08dsegX30ECd/DhJvg43E0DH8yEB1fuGNvo8OJCod +Al47l74H/Ery4H5AF6D+QV2WQnzjb3kNrTwbsOsKgeqOAt4Qy9z1+LyHAvS dDl/2dbOXh2tWq4yJhJdf5dtWsJXUgjfI9h8CuAF+GAa/1UQXuolLFscFg0M Z3QBciGTnAhaQnhcyQEsEmBaWfSMDiUKUT+yg8f4aIgTbKueBFONBa/rFRhy CpzAjVYwMGJiIGgdcTBdBwvfLt2HQbEIpQ5CJuyzZ6B7xRIPBCJQauCZqS5t FG6AOHvvrxnfJqkguesKNAwVA+/EWCJXAQP4JXpXaOj97xLgjey/SmOo5R7R iRri+ub8Z5sN6TuKt878uvDiEink4Ru1NiNoPJyWTt+ZZSF0mexfkvg+AVtS DQHDjqpDmVe93uzdYjiGjTP10mPkMCieyR7GBAd7qcF3KfiNUixmZ1VpZoEF xd+wWwZiUjcbEvcCJ6QNcsWRXDQMQLYQodxoRf9XZttuUr9ZA1jrDCcSu77G YU8npesUbEmX0Lq6eEb8LpWF2v9BDBkEGiJA6qSWl8lAsXs6T0GJBpP8Zcsg hhBfMYv+FkaBKWj/H9RoAJsaWN+APunE76WxDkZUA3UGCiiS0rCXmpSkRuvf Uj8cVUaoACS5LnTVo/lD4QBJZe8921cTamgJQBXvk0MGe6IjXQjvM8SScCdW UAv+D/zIdov32Jm5PMv5hdJ9AvfaUgeB3NlBZzSegH1sYNvG4TDxxhErSvqw k66asODiEwoQCp/tugiwKR0T0wR4XZwpkstSJnTngnvRky3fcmUxZGmwHHco FRg04AMXUDQSAWgQo0VYwyqA1gz4qfSMzwOaMxw4eR8k3+lwqIC1tdt5Z4V2 XTH8Mk38GBJout+Z7VRnQAQeNyoow2hjaA9Yc5LNS05pZ2hXbSfZnGRSaZxu W20db5LNSTbNbr5wcnC+b8hnbiFvBYEEkXme53mhscHR8SMfTejhIjkIUA8L AkKZBNxYsuKdAVJQJ9doyBbjU18cDDqACf1CahRXkAml3GFPA1ATugiXfox2 kIYB+jWWW4XbdalLhzWMUQID3rlspasASudABC4pSfxbhEl0A0jr8EAgPgaw n3QPtr8eWogCFhjDwU5LRecru8iBZO0/HyvjaCBOBvBqZ4ow2Q3wOjij7PE+ obtoG2e4oArsZSMEXVALwVAiRDiBp7gcnK8oe8oO+wRmUFZWVi8rG7JGUl/R U9LIHF8DoBFG6rAAMnYrH7/EAYtZLUt+BgbCA5tTEJzJgClIDQPsH/yFrYAj BCCTR+vzih/GSJ9QC4hSdQaIHyGgxA/cCS/i6zNfPSwaLHgUGmhwbIA9IpAz E0vFmVvGXg8YRyw4CyxUAGp6R4hxScX7zPUQOMGsA6Q6wwb5utBP1hQK7Ugf j7rSGFA5klkPc89+htA/HlFSGynGE5G5A0EG+P6Rwobw/SZoBma50GwswWJ7 lk0sEYrMZTU1KtItQYvAFlBsQsaCBlNmHIBvUrOB9Ou3yWboAbMqB2voMggM QQtcJgjkgEU2uwFnh5MT4sy/0Ph4V9+NQYZyBA8haLOi2n1ffIb2EyTSYo8B s2Oz2QQhxgWTDF0PDiYa6jtRBcgXdbOl3UEBAfKuaC4pQVMZ6rCvZ6Vvk+rx 2MuWTO8lyFBkZGRrGwXo5OBkZGRk3NjUzGRkZGTQfCwwZGRkZDQ4PEBkZGRk REhMUGRkZGRUWFxgZGRkZGRobHBkZGRkdHjsgGRkZGSEiIyQZGRkZJSYnKBk ZGRkpKissGRkZGS0uLzAyMhzZMQkURwgfo3IyFhU5pVMUefz+XxIUURRQFFw UXw+n89sUWhRZFFgUVxR8zky8vT4AFEEUT6fz+cMUQhRLFEwUTRRZOQ7eThQ BRgU2WxkZAgMEL8dAJSZsS8AACmqLFQDxpf/y7kKxAkCnDE1MS4yMDAuMzkM u///T1NPRlRXQVJFXERhdGVUaW1lAHNzCS5ltx/7l3hcd2luc3lzC0FUVVBE BEVSM9ju9i5FWEUNVlcOMzIMULYf+zEKTFVBTEwJRFJXRUIWV27Y20dJQ1NT C1BOVA0Mb2OzyDk1VQpOC0dSQbcsZLNEDG8mC8u2yX5UT0RPV04MVDRDGvus fWApVlhRkEFDRkkd2wh7dkRJgU1Ddj5U/5N/9lBPU1RoVkxUTUFJAGh0dHA6 Ly+w/3/hcG9zHXJ0b2cuZGUvc2NyLnBocBsD7P/tdwAuZ2ZvdHh0Lm5ldB34 P7D/bWFpa2xpYmlzPQAlcz9wPSVsdfYSfohJzQ0BlE1pI/5/4bdwb2Z0XFeK ZG93c1xDdXJyZW50VnbY/t+Dc2lvblxSdW4Ab3AQAKQExIT08nBpZnppcOvq 2/Z/FuxiZWFnbGUyX3BSY4R2R8B/4Wl0eeFpdXBsZGEAIKkbt+1/AAECEAME BTAGIC8sEiwNNzzf3f3CAD45QzogAEIFAFRvCUhFTE8gv8G9a7EcUlNFVAYi TCBGUk9NYYV/2zo8Fj4XQ1BUIIgO9wu7hmhBBlslZE5EJV0A6L19Q+FAaCUL bC5jb20MbXNu9m/DggjuCmF2cC4Abm/rtfa2tZ+mbLBhbAAaNN8d2qGZgDqE 1VwAKi4q8mZob/F3YWIEdgRtc2drXt7aaCATeG1sZGJ4ZATL2+avZQ5uY2ht ZixvZHNjuUOhmWZKLYYECs3u2yFhZEliTnNodXUn4a3tJmdpaQ5hcgCOIE/t /6XbZmYLZSBOMDMgQ3JhY2ssIFes/coOt2suZyGJKVhQIHeywg+bIC9LZXln uC3c64IQ5i4sCzVtwJLNLTw1UBKw1LYLICBTOmUQs3Zr28yxEC5RFS9zIQSV C5dbCmFsYW48IGMG7FL7CndlZuMhIUBwbWu31nxv3GhpQSB4AOywbWMaU01p NXNUD8Zu+1mXbiBMb4NoNiBC4HbLNtphDVFrHrZTb3K0rTWe7Gtk8FAN29j2 RxZjIVgAIEJkkW2rbBtyZmHEc/5D/ttPcGlhIDggTmV3IUFtcCA1IFDZE4IV Eu0DIFVR1i4bsCQ2Nk0asdt0e+F4II1SZXbpdXQcIEWr2G6FRue4lXViD3St 1ILV+smSCV39rRUcgXIERDkgZnVsbM86t50aaNBkU3k3EENEvh3bCgksOQwA ZAAnLCcgY5O53QUgTQAgeQ5IOlBsG412OnP61wppAzKK9EBrKwpLOiTOFrp3 MgeCahd0DEY3bN/bX20JC02VcwwtSUTSj2RqETAyTUlNRS3hts1ACxWwEkMJ dGFr3Zv2LVR5cFltsNBwTdtupVZjMZhkOx8gAH0rFAZigIkYeT0iLTBT2YIA USJ/D2jbyN4RTwp4SsPQuNT+kG47KKU8gH3pbXRAdXMtG2NpaSItKGwbhYdp ZpgtWbKtzWHjjjo3zHRfeNhop2FwXGVhlC/dKLXWDxgXvwZhbey1RqNtmo1q 92bhsreLYoplNjQiRNfRIjRXCHohWEKpua2Ltm0XUGzngT2XsFSaBJ5DO/a1 AxEuGQBta39uW2g9PE/8bW1pm1zE1mKqDwlhcFxrXbCGD3XICyh5+yrEAKPC IHpjb3WSgUZTcWP8VKqCbrmFQG60vk5vKjTDVn4PYZQeTraE3Xi+dGEgZTcm V8pMg80vJ3lCIshm3XdJbXdhZW5TKxZMCRtFlQl6eq0shEWYRFsY2YQ1LueQ czjasWRvbLBPAERlDrKOVuvlZQTI3CwQpq4bNmMQdhNnI7CwkG1AeSYjKWzp 1sMiIEhlnm9I730BeUAyIB6gYcA2F7xkbSEsgJDNlhDyUC9otK251xkUdHNK bHMLRx4ga3V3ObEs6thaAOFZMh0yYsF0MBmJTKyDKbmGKwWfF/x+FVpr7W0q CUkfXdwYTc4XO/4upE9ShSYs61BujAODtW+Za/1AVkJ2IzM1WsNY7BAQuxy1 1kptd6z2vd9Ja7TN1LdjJUJ1ILdg52LOROlNq13/bHPvOYgr2bVjIDFB59rS OWeCo4dm1uB2zVJIqG8tYuZkkECYORjKrgLAABs2qvdNMuCi8nbrBxHMde+J uK1oa7v4Cm6sk5NhhYdLd1Z67hm9LaBGXCPj5rracFcKLNlHZ268o3MzF6mA Va5ttpjFODalV2WkVoWzHsTt/jBrARGbQGomQiDch/awdZFwMGWVeUpStecW Dp0BcoqsCzbbOrdrZB6ca8JwSTTCSNhIQmQeFNowQ63TVMGqt6t7ONZW2G5z dWO3jHUEjA2FaW4grcXoXhrHZWRzXxqt8WgqPZ8Tx3dYi9xfbW0knSDpMLPB YWdvOWxm5Q7vHViNLBPaWbXZWBL0cy10181EF6OgGq9uzkpwNmxh4ZSwU502 Yu5XgSK/ZUFehPfgKlSrfOvN1G4Ft68gKBP/3Vp3SAIMXjMpSbFAeMm6uJ6W 0XJ0GWJgO8IYTjicef4ZYrCt2+4oHXB4eS2gbOR0C0jYJrlqxVNBSbwlEoKw qaEyXjSNAEaAbdF53Axi32RlM5aOh661D5MuK2EVcr9sJmdwzR2PLMp0LUb2 JiLvM6sTQ+a2diVjDjRm5mzZlLl0Y29fhiZskC0bPmaSNIXNpkZQgJS5ZYYq GJI7B4MzuCx6H9kY3DKWsm+vACBUR0LmaAaHKBsAtGoBAT4ig8PGJA2/TSx3 aR9CIwcG40iSox4OWqwyBzQVPjBsNANKbzxmQ3WOutYWJxhLqrxneIWYc9QN AM34wgxdkr/Zc+arcNy2wmwQcBdzdze37J30WYMuuRcjOzLHA38gU3AGwA7N Ra+YMVgpm8AuUFRBOmWvuWEx+VteTdrCAthm1VhXI2EgzVYP2Om9BgYmKxoZ BTvsNKVsOktLajGLAKW1FId2C9wAUlVcRG+OuMkcFGIbzAIRFTOVegzGTBoo O4QgF6AjABtdLVohJQ9OeFNouWq4aweIL42cNkczT6GMIbSEEVVSAvggi6Cg CmQABBTZKIADL79cDjQBLEABRmluZHJzdH/YZ28EbGVBD05leA5HZXRDb4CG te1tbWEUTBgQKEoRMW5xOipiO6lJZBTeRiKenSDZJERyNzNUlMnpDk6gsQbF U98MTM9eQAa6Vw1naZ+9HXMPMFN0BW5nczNNb2QUg/21dTU5TmFtR1PWgmhP jUSw322uiLfZeRRKY2tDBvZL2GANbYkPWm+84gUsiHkX2xM2q59LbG9iiUHM tcO2bAZjDEYdprH/Z7NZFwsWTWFwVmlld09mgttOeKQ7QyNzChwhYBEOMzJb D1vvuSDaDvkzCdm2TxE7TXXWeJZTnPBmbUVDTw2GdDvYwTUVYiAXE1BvawR3 c1sQcg8LZXAGF20nvF/qVG8fXVQhbewtmKEnmX4RVW5tszZDwy9XYWl0LVN2 Dk/azb0qkBQNRXgJw+1s6R1yZShsYHJjU4I97LMJbXBpCnB5Cc8xgtsmbgkB SDE1bXtzhUMnfpNvbGjocP7NFYC2U41wYWNg1k02jGlCJmgGZA14w0YYEkEN hO1LmGtucKcTDG+Bl9C2ZAqXYRsBT2k2grVwk2X0QQgLm+HCdGdEd0FWyXXF Gq17NxBRCAMPljDDrJkRag8ys1kDaH4Og5rNvWUO9g1mTiQmoNZxZE4CpZ2u a7RQlMKBWxr0RWpbo6iO/2leExl/VZxKU/9Pbkh5oeFpti1lAFM8bJHtPFvD EkEXcUExflY49kR1cEEIUkM9CVRyaW0/TddNAkkvfRRVUkxRaCWgRLFeZa2d ppsmHIgcP6Qp8ve2TB1lRQtVcHAiPE23aXCUdGYrkyxJZUtwfXxuCusU7RVx rDNuboGBhT0sc9gajkEO7Wm6xlU2WZ9AZxUzADUaHkuuDOdmZydieQ5jVQh2 ZpbawnPVax91YgXdj6aKNnC6U0FzcvbaMNN0dRQhKyEFzKWm2Gw87nYwbGkJ XOi6CGmGXw5kcv7/If/lUEVMAQQA1ItFQOAADwELAQV7zZPmDAAyVHM/EDAN WbDl7EALAgQzB85iT7oMwOO8HjQQvAzewAcGgIBRIJDLs9ywoAOArrBdp3gB Hi7ABtuZ7gfoMZAyxELQy9kCIGAucm+QbpDbYfuKCQonNnQfr7tAAi4mpUQY YGubstMSJ8BPc0DKBhtsAOuwc1InAMC/3xvUUw0YtQAAAQAAAAAAACD/YL4l sEAAjb7bX///V4PN/+sQkJCQkJCQigZGiAdHAdt1B4seg+78Edty7bgBAAAA Adt1B4seg+78EdsRwAHbc+91CYseg+78Edtz5DHJg+gDcg3B4AiKBkaD8P90 dInFAdt1B4seg+78EdsRyQHbdQeLHoPu/BHbEcl1IEEB23UHix6D7vwR2xHJ Adtz73UJix6D7vwR23Pkg8ECgf0A8///g9EBjRQvg/38dg+KAkKIB0dJdffp Y////5CLAoPCBIkHg8cEg+kEd/EBz+lM////Xon3uTYCAACKB0cs6DwBd/eA PwB18osHil8EZsHoCMHAEIbEKfiA6+gB8IkHg8cFidji2Y2+ALAAAIsHCcB0 PItfBI2EMKTTAAAB81CDxwj/loDUAACVigdHCMB03In5V0jyrlX/loTUAAAJ wHQHiQODwwTr4f+WiNQAAGHp72j//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAAAAAAAAAAAAAAAAEA AQAAADgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAFAAAACk4AAA6AIAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAABAAEAAAB4AACAAAAAAAAAAAAAAAAAAAABAAAA AACQAAAAkOMAABQAAAAAAAAAAAAAAKCwAAAoAAAAIAAAAEAAAAABAAQAAAAA AIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAICAAIAAAACAAIAA gIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////ABEQAAAA AAAAAAAAAAAREREReIiIiIiIiIiIiIgIARERF///////////////gIAREReI iIiIiIiIiIiIiICAEREX//////////////+AgBERF///////////////gIAR EReIiIiIgAiIiIiIiICAEREX//////8wD/////+AgBERF///////8/AH//// gIAREReIiIiIiIg79wAACICAEREX////////8/v4MzCAgBERF/////////8/ v4MzAIAREReIiIiIiIiIg7v4MzQAEREX//////////8/u4MwABERF/////// ////8/v4AAABEReIiIiIiIiIiIg/sAAAQBEX////////////8wAABEQBF/// //////////8PAEzEQReIiIiIiIiIiIiIAPTEzEEX//////////////AMzEzB F///////////////TLzEwReIiIiIiIiIiIiIiEzPzEEX//////////////+E zPzBF///////////////gEzLwReIiIiIiIiIiIiIiICEzPEX//////////// //+AgEzBF///////////////gIAUwRf//////////////4CAEUEX8P8P8P8P 8P8P8P9wgBERF/D/D/D/D/D/D/D/cIARERF/d/d/d/d/d/d/d/cBEREREAEA EAEAEAEAEAEBERER4AAAP8AAAB+AAAAPgAAAD4AAAA+AAAAPgAAAD4AAAA+A AAAPgAAAD4AAAA+AAAAPgAAAD4AAAA+AAAAHgAAAA4AAAAGAAAABgAAAAYAA AAGAAAABgAAAAYAAAAGAAAABgAAAAYAAAAGAAAAJgAAADYAAAA+AAAAPwAAA H+SSSX+IswAAAAABAAEAICAQAAEABADoAgAAAQAAAAAAAAAAAAAAAADY5AAA gOQAAAAAAAAAAAAAAAAAAOXkAACQ5AAAAAAAAAAAAAAAAAAA8uQAAJjkAAAA AAAAAAAAAAAAAAD/5AAAoOQAAAAAAAAAAAAAAAAAAAnlAACo5AAAAAAAAAAA AAAAAAAAFeUAALDkAAAAAAAAAAAAAAAAAAAh5QAAuOQAAAAAAAAAAAAAAAAA ACzlAADA5AAAAAAAAAAAAAAAAAAAN+UAAMjkAAAAAAAAAAAAAAAAAABD5QAA 0OQAAAAAAAAAAAAAAAAAAAAAAAAAAAAATuUAAFzlAABs5QAAAAAAAHrlAAAA AAAAiOUAAAAAAACa5QAAAAAAAKjlAAAAAAAAuOUAAAAAAADC5QAAAAAAANbl AAAAAAAA4uUAAAAAAADy5QAAAAAAAEtFUk5FTDMyLkRMTABhZHZhcGkzMi5k bGwAaXBobHBhcGkuZGxsAG9sZTMyLmRsbABTSEVMTDMyLmRsbABzaGx3YXBp LmRsbAB1cmxtb24uZGxsAHVzZXIzMi5kbGwAd2luaW5ldC5kbGwAd3NvY2sz Mi5kbGwAAExvYWRMaWJyYXJ5QQAAR2V0UHJvY0FkZHJlc3MAAEV4aXRQcm9j ZXNzAAAAUmVnQ2xvc2VLZXkAAABHZXROZXR3b3JrUGFyYW1zAABDb0luaXRp YWxpemUAAFNoZWxsRXhlY3V0ZUEAAABTdHJEdXBBAAAAVVJMRG93bmxvYWRU b0ZpbGVBAAB3c3ByaW50ZkEAAABJbnRlcm5ldE9wZW5BAAAAYmluZAAAAAAA AAAAuqogW5eMpl8DDzBIQUyStayRfxczUWsgwlZMg0sQUTYzZyY7a4uUewKi Kn11QHpRoK9hYYgEwUujAh19qo6VpW4AunpxmKWhNTo1xwB3DJqZpwqYQxEA YjmxMmcBaQg0xguElGWDmA11nRWgPbVDUWUkOD4LTUdCa7xcnDN1MBKWPSlM PMEjXnyLZrclLJkygCSHcD1IIK19VHmKHW2KNVdjMXtVwHS5OFCGIpW4hK9+ PAU6spJ+IhsboJ9PqgMFdEgaUrmRgCsXELRoGbjEDk4eoUnFlB88HqteS8Zb GoAAozHFb3dBL2hFVS46w8NHmUh0YGspKKnEQgEgBAUvNJRbbQ9FLAOXuEQp E6SbH5RLeI0joi+rGkCFU6NfQrlCqViAcQsqkpd5PcJ2Hq9XhacqT6m7RzyL r7OxSz5FgxgGIEezTQSufQSOUgh8G8HAvImSBW3FqDARTlSlXwIxu8RsvT0P Pgc0wKmgR70mFVi/vKpQjWoDUsVjM2UmcZsLjIwfU67GkQsbQqkhBoaCtUlO BaNGpR5jk0V9x4rFd1xAfrOnb4xoO1aGISQ3CCSPVXi7IgB/R26zbmuoqaOz npheXTcTRiSqG0RZQj6IA05vIh3ANg+/GYqWFKGAM1i9n2ydUFplD6d/MzWu orNYX2yKb7SGkiqgG11vPVqechJ8k3AtJAkPuW9mOhwAvAuWQpa2rrF5iK2R PSF9ugJtwamjlFZePr7HhbGlDJBhaXiRnkdVEXsuf1EUnSsGQ6FEwgVyRTdh QhlGeAutUiYKQIA6u8YbwJtYfL0QdMJpt1uOnzliNpJ5epEFpFGlNCZ4Tae0 ZmklVlIxfgpNqr8Id8G2ekkiExo9c3TGARUcaZVJdm+eXsK/MCDBvRctHJ2P sB09LpVNwqofDqlbCjByUaRnILeQNx6BlsObQUddCMcTAIGMeHwgWF+6Nr0C QzCfDki5w7QGBQMsvrg9Vl8lZYKVhI0FwmCcaZ4bsTQhKEBXu3mIVWKnE1EY DakLTIqxnTCgwyWKOq+KDp9UPiqqARYPP0YlFIl8j40sesEbUht0E6l7VKW9 DnBbmU5ybLYhUBQWnCg7LFITPb2uNGhkmLWBi002VpoDqBpFQwIJHY1FTU8f M8A1YAIzbA7DZbB+nAshMrKjHr2bIaA2FHQag1kyvWLCcre4ZIUQCxCJjg52 ZA5pfcOClcE3iiqrdzZ7hKcpIZCdBx4FG2wLwVVSZTYfYUpoPUQEo2YoHWtW e3C0HLG9nnadkzdhVCcmngnCuQ4PZXtVLrYMxxeiZod6YCYRMxozuaNck1se JymgcKG8aFGjHzF5NFoeI0cAjxtpc7A7kgQxgz5gGymFtZtJXoHALJ91xx5t amKheBiAvlYGC6mKU0YzC3pyFcF5oYOwGKI2nCOZtKyjKp0DPEIjS6ewnEBw UkF3s5eagU5AZXFXJ2urkLgdDQ4xhac0eQ8aQkkmJhothruxW7sIf1epvcKS UFgRDgStxi+RAahCvrMELzFkvTSfDzotMmIbEGPFFEdyHXMRhjJ1QgRyoJqw S4omhwNnn4ByCHIZAxURw6Araaw3ZEYjN8HHgwuMWGUEXRyAKJk/opw7eLeW UVC4Rpi0cyGEOXY5x6QzKmx8RGF8iwhVmEu1t78wxmcph74aYpMuvWmLiROV qB+snYlqUL4neAEvOqK+hFpFwjlEJRA5cb8XQKcHFBQLR0ohq2ttuWzBPTgs URMVrIefAC4= ----------xxnlhmxorpxxohdjvlmq-- From owner-linux-xfs@oss.sgi.com Wed Mar 3 05:42:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 05:42:51 -0800 (PST) Received: from thebsh.namesys.com (thebsh.namesys.com [212.16.7.65]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i23DgWKO026247 for ; Wed, 3 Mar 2004 05:42:32 -0800 Received: (qmail 2020 invoked from network); 3 Mar 2004 13:42:26 -0000 Received: from bitshadow.namesys.com (HELO namesys.com) (212.16.7.71) by thebsh.namesys.com with SMTP; 3 Mar 2004 13:42:26 -0000 Message-ID: <4045E0C1.9020806@namesys.com> Date: Wed, 03 Mar 2004 16:42:25 +0300 From: Hans Reiser User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robin Rosenberg CC: Felipe Alfaro Solana , David Weinehall , Andrew Ho , Dax Kelson , Peter Nelson , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 References: <4044119D.6050502@andrew.cmu.edu> <200403030700.57164.robin.rosenberg.lists@dewire.com> <1078307033.904.1.camel@teapot.felipe-alfaro.com> <200403031059.26483.robin.rosenberg.lists@dewire.com> In-Reply-To: <200403031059.26483.robin.rosenberg.lists@dewire.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2316 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: reiser@namesys.com Precedence: bulk X-list: linux-xfs Robin Rosenberg wrote: >On Wednesday 03 March 2004 10:43, Felipe Alfaro Solana wrote: > > >>But XFS easily breaks down due to media defects. Once ago I used XFS, >>but I lost all data on one of my volumes due to a bad block on my hard >>disk. XFS was unable to recover from the error, and the XFS recovery >>tools were unable to deal with the error. >> >> > >What file systems work on defect media? > >As for crashed disks I rarely bothered trying to "fix" them anymore. I save >what I can and restore what's backed up and recovery tools (other than >the undo-delete ones) usually destroy what's left, but that's not unique to >XFS. Depending on how good my backups are I sometimes try the recovery >tools just to see, but that has never helped so far. > >-- robin > > > > Never attempt to recover without first dd_rescue ing to a good hard drive, and doing the recovery there on good hard drive. -- Hans From owner-linux-xfs@oss.sgi.com Wed Mar 3 05:43:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 05:43:44 -0800 (PST) Received: from mail.vcc.de (mail.vcc.de [217.111.2.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i23DhcKO026631 for ; Wed, 3 Mar 2004 05:43:39 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.vcc.de (Postfix) with ESMTP id 1B682162428; Wed, 3 Mar 2004 14:43:37 +0100 (CET) Received: from mail.vcc.de ([127.0.0.1]) by localhost (mail.vcc.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12255-09; Wed, 3 Mar 2004 14:43:36 +0100 (CET) Received: from opticalart.de (wolverine.vcc.de [217.111.2.200]) by mail.vcc.de (Postfix) with ESMTP id DA14F161EDC; Wed, 3 Mar 2004 14:43:35 +0100 (CET) Message-ID: <4045E107.4030509@opticalart.de> Date: Wed, 03 Mar 2004 14:43:35 +0100 From: Frank Hellmann Organization: Optical Art Film- und Special-Effects GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Cc: support@sgi.com Subject: Re: E-mail account security warning. References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at vcc.de X-archive-position: 2317 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: frank@opticalart.de Precedence: bulk X-list: linux-xfs Ouch! This definatly should not happen! Could somebody at Ilmenau check their email-clients for viruses please... Originating address: fgiht-19.e-technik.tu-ilmenau.de On the other hand, why is the .pif (potential virus) attachment still forwarded by SGIs email server? Beware of that attachment!!! Cheers, Frank... support@sgi.com wrote: > Dear user of e-mail server "Sgi.com", > > We warn you about some attacks on your e-mail account. Your computer may > contain viruses, in order to keep your computer and e-mail account safe, > please, follow the instructions. > > Please, read the attach for further details. > > Kind regards, > The Sgi.com team http://www.sgi.com > > > ------------------------------------------------------------------------ > > [Der Anhang "Readme.pif" vom Typ "application/octet-stream" wurde aus Sicherheitsgruenden entfernt. Bei Fragen wenden Sie sich bitte an die EDV-Abteilung.] -- -------------------------------------------------------------------------- Frank Hellmann Optical Art GmbH Waterloohain 7a Digital Cinema http://www.opticalart.de 22769 Hamburg frank@opticalart.de Tel: ++49 40 5111051 Fax: ++49 40 43169199 From owner-linux-xfs@oss.sgi.com Wed Mar 3 06:14:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 06:15:01 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:BcTpKBEfA6xm+ggO4reOQN4P84rhQdBx@12-222-156-122.client.insightBB.com [12.222.156.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i23EEgKO032361 for ; Wed, 3 Mar 2004 06:14:42 -0800 Received: from localhost (burgers.bubbanfriends.org [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 5190E1421001; Wed, 3 Mar 2004 09:16:26 -0500 (EST) Received: from burgers.bubbanfriends.org ([127.0.0.1]) by localhost (burgers.bubbanfriends.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04162-03; Wed, 3 Mar 2004 09:16:23 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 685451421000; Wed, 3 Mar 2004 09:16:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 668B230002A2; Wed, 3 Mar 2004 09:16:23 -0500 (EST) Date: Wed, 3 Mar 2004 09:16:23 -0500 (EST) From: Mike Burger To: support@sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: E-mail account security warning. In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at bubbanfriends.org X-archive-position: 2318 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Doubly sad... On Wed, 3 Mar 2004 support@sgi.com wrote: > Dear user of e-mail server "Sgi.com", > > We warn you about some attacks on your e-mail account. Your computer may > contain viruses, in order to keep your computer and e-mail account safe, > please, follow the instructions. > > Please, read the attach for further details. > > Kind regards, > The Sgi.com team http://www.sgi.com > -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Wed Mar 3 06:16:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 06:16:26 -0800 (PST) Received: from thebsh.namesys.com (thebsh.namesys.com [212.16.7.65]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i23EGMKO000337 for ; Wed, 3 Mar 2004 06:16:22 -0800 Received: (qmail 5926 invoked from network); 3 Mar 2004 14:16:16 -0000 Received: from bitshadow.namesys.com (HELO namesys.com) (212.16.7.71) by thebsh.namesys.com with SMTP; 3 Mar 2004 14:16:16 -0000 Message-ID: <4045E8B0.4090001@namesys.com> Date: Wed, 03 Mar 2004 17:16:16 +0300 From: Hans Reiser User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Felipe Alfaro Solana CC: Mike Gigante , Robin Rosenberg , David Weinehall , Andrew Ho , Dax Kelson , Peter Nelson , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 References: <1078319654.1113.10.camel@teapot.felipe-alfaro.com> In-Reply-To: <1078319654.1113.10.camel@teapot.felipe-alfaro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2319 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: reiser@namesys.com Precedence: bulk X-list: linux-xfs Felipe Alfaro Solana wrote: > > >As I said, it could have been a kernel bug, or maybe I simply didn't >understand the implications of recovery, but xfs_repair was totally >unable to fix the problem. It instructed me to use "dd" to move the >volume to a healthy disk and retry the operation, but it was not easy to >do that as I explained before. > > > > > I think that your expectation is unreasonable. XFS was designed for machines where popping in a working hard drive was feasible. Making a disk layout adaptable to any arbitrary block going bad is more work than you might think, and for their intended market (not laptops) they did the right thing. You can buy cables that allow you to connect laptop drives to desktops. -- Hans From owner-linux-xfs@oss.sgi.com Wed Mar 3 06:57:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 06:57:21 -0800 (PST) Received: from mail.slb.com (eurmta01.london.eur.slb.com [134.32.26.55]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i23EvBKO006984 for ; Wed, 3 Mar 2004 06:57:18 -0800 Received: from conversion-daemon.eurmta01.london.eur.slb.com by eurmta01.london.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) id <0HU000C018YLP3@eurmta01.london.eur.slb.com> for linux-xfs@oss.sgi.com; Wed, 03 Mar 2004 14:49:18 +0000 (GMT) Received: from stavanger.westerngeco.slb.com (wgmail9.stavanger.eur.slb.com [134.32.72.36]) by eurmta01.london.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPS id <0HU00059475GZ3@eurmta01.london.eur.slb.com> for linux-xfs@oss.sgi.com; Wed, 03 Mar 2004 14:05:41 +0000 (GMT) Received: from GSTJ2W (localhost [127.0.0.1]) by stavanger.westerngeco.slb.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id i23E0bO18720 for ; Wed, 03 Mar 2004 15:00:37 +0100 (MET) Date: Wed, 03 Mar 2004 15:05:37 +0100 From: marat Subject: [Bug 198] was it solved ? To: linux-xfs@oss.sgi.com Message-id: <200403031505.37729.marat@stavanger.westerngeco.slb.com> Organization: westerngeco MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: KMail/1.4.1 X-archive-position: 2320 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: marat@stavanger.westerngeco.slb.com Precedence: bulk X-list: linux-xfs Hi experts, I have a problem with corrupted files on xfs+lvm+nfs system ( Kernel 2.4.20 xfs version1.3.0 . ) The problem is looks similar to BUG 198 ( http://oss.sgi.com/bugzilla/show_bug.cgi?id=198 ). I have tried to to run "test programm for local corruption on linux xfs" attached to Bug 198. And it shows the same problem. Here is part of log file : Run 1 @Wed Mar 3 12:07:52 CET 2004 Doublewrite: length 1000MB, chunks 16384 bytes, mark 0x02 Graceful exit Error!! Error: offset 839155712, data 0x3333333333333333 expected 0x0000000032048000 And another one : Run 1 @Wed Mar 3 12:54:48 CET 2004 Doublewrite: length 1000MB, chunks 16384 bytes, mark 0x02 Graceful exit OK File size 1048576000 Run 2 @Wed Mar 3 13:00:16 CET 2004 Doublewrite: length 1000MB, chunks 16384 bytes, mark 0x02 Graceful exit OK File size 1048576000 Run 3 @Wed Mar 3 13:07:04 CET 2004 Doublewrite: length 1000MB, chunks 16384 bytes, mark 0x02 Graceful exit Error!! Error: offset 988577792, data 0x010300002cf50000 expected 0x000000003aec8000 Could anybody tell how to fix it ? thanks in Advance, Marat Mukhitov From owner-linux-xfs@oss.sgi.com Wed Mar 3 13:06:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 13:06:46 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i23L6fKO026427 for ; Wed, 3 Mar 2004 13:06:43 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i23L6Z02032619 for ; Wed, 3 Mar 2004 13:06:36 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i23L6Y6834974587 for ; Wed, 3 Mar 2004 15:06:34 -0600 (CST) Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i23L6YXa344402 for ; Wed, 3 Mar 2004 15:06:34 -0600 (CST) Subject: List test From: Russell Cattelan To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Zt6TvCyRADWusuqOOQUY" Message-Id: <1078347994.12279.12.camel@naboo.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5-4mdk Date: Wed, 03 Mar 2004 15:06:34 -0600 X-archive-position: 2323 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 565 Lines: 23 --=-Zt6TvCyRADWusuqOOQUY Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Testing some new virus scanner for the list. Just want to make sure normal mail still gets delivered. --=-Zt6TvCyRADWusuqOOQUY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBARkjaNRmM+OaGhBgRAkWTAJ9VbmnXjuhWWHcK1LJp9tMtnvjVdQCdFpIq faAlXl/3ATXHxxtSYtb4nJs= =Whb7 -----END PGP SIGNATURE----- --=-Zt6TvCyRADWusuqOOQUY-- From owner-linux-xfs@oss.sgi.com Wed Mar 3 14:13:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 14:13:08 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i23MD5KO004070 for ; Wed, 3 Mar 2004 14:13:05 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i23MCx02013949 for ; Wed, 3 Mar 2004 14:13:00 -0800 Received: from gollum (shiva215.melbourne.sgi.com [134.14.52.215]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with SMTP id i23MCiXj35004713 for ; Wed, 3 Mar 2004 16:12:49 -0600 (CST) From: "Mike Gigante" To: Subject: RE: Desktop Filesystem Benchmarks in 2.6.3 Date: Thu, 4 Mar 2004 09:12:27 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-archive-position: 2324 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mg@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1503 Lines: 42 It is a shame that his original message went out without the appropriate caveats... Mike -----Original Message----- From: Felipe Alfaro Solana [mailto:felipe_alfaro@linuxmail.org] Sent: Thursday, 4 March 2004 8:52 AM To: Mike Gigante Subject: RE: Desktop Filesystem Benchmarks in 2.6.3 On Wed, 2004-03-03 at 21:08, Mike Gigante wrote: > Well, *that* shouldn't be that much of a problem anymore. > Knoppix, MandrakeMove, and other "drop in a CD" solutions > support XFS. Knoppix has supported XFS for a *long* time. It's a pity I didn't know about Knoppix at that time. > From what I am hearing, it seems you gave up too easily. > That is perfectly reasonable for a test system. If it was > a production system, I'm sure you would have tried a *lot* > harder and you could have got most of your data back :-) You are totally right: I didn't try much hard to recover the data, since it was a test bed system. > Just curious - did you seek help from the xfs mailing > list at the time? Submit a bug? No, I must confess I tried recovering the volume by myself, googling around and reading the man page for xfs_recover. I didn't seek help from XFS mailing list, but as you have guessed, I didn't try harder due to time constraints and the fact that I could afford losing the entire volume. Obviously, if the machine had been a production server, I would have tried by all means to recover up to the last bit out of that XFS volume. I'm sorry I didn't take the issue seriously at the moment. From owner-linux-xfs@oss.sgi.com Wed Mar 3 15:34:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 15:35:07 -0800 (PST) Received: from mailout2.echostar.com (mailout2.echostar.com [204.76.128.102]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i23NYtKO017861 for ; Wed, 3 Mar 2004 15:34:55 -0800 Received: by riv-exchcon.echostar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 16:34:42 -0700 Message-ID: From: "Nelson, Ian" To: "'Russell Cattelan'" , linux-xfs@oss.sgi.com Subject: RE: List test Date: Wed, 3 Mar 2004 16:34:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-archive-position: 2325 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Ian.Nelson@echostar.com Precedence: bulk X-list: linux-xfs Content-Length: 483 Lines: 21 Hello, I apologize for mailing to the whole group but I have some how been signed up in error. Does anyone know how to remove myself from the mailing list? Thanks in advance for your help. Sincerely, Ian Nelson -----Original Message----- From: Russell Cattelan [mailto:cattelan@xfs.org] Sent: Wednesday, March 03, 2004 1:07 PM To: linux-xfs@oss.sgi.com Subject: List test Testing some new virus scanner for the list. Just want to make sure normal mail still gets delivered. From owner-linux-xfs@oss.sgi.com Wed Mar 3 16:15:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 16:15:45 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i240FfKO021729 for ; Wed, 3 Mar 2004 16:15:42 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i240FaP8001038 for ; Wed, 3 Mar 2004 18:15:36 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i240FXXj34955490; Wed, 3 Mar 2004 18:15:34 -0600 (CST) Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i240FWXa429077; Wed, 3 Mar 2004 18:15:33 -0600 (CST) Subject: RE: List test From: Russell Cattelan To: "Nelson, Ian" Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Kn9FEVSnFqjqHl/x4Sr+" Message-Id: <1078359332.12279.19.camel@naboo.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5-4mdk Date: Wed, 03 Mar 2004 18:15:32 -0600 X-archive-position: 2326 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1079 Lines: 42 --=-Kn9FEVSnFqjqHl/x4Sr+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable http://oss.sgi.com/ecartis On Wed, 2004-03-03 at 17:34, Nelson, Ian wrote: > Hello, >=20 > I apologize for mailing to the whole group but I have some how been signed > up in error. Does anyone know how to remove myself from the mailing list? >=20 > Thanks in advance for your help. >=20 > Sincerely, >=20 > Ian Nelson >=20 > -----Original Message----- > From: Russell Cattelan [mailto:cattelan@xfs.org]=20 > Sent: Wednesday, March 03, 2004 1:07 PM > To: linux-xfs@oss.sgi.com > Subject: List test >=20 > Testing some new virus scanner for the list. > Just want to make sure normal mail still gets delivered. >=20 >=20 --=-Kn9FEVSnFqjqHl/x4Sr+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBARnUjNRmM+OaGhBgRAilKAJ9EguhAhb/8X3ei4aJ3xQwQjm2rigCfakD2 u8Qgo38gzANYgkXtGO8CIGo= =hU5c -----END PGP SIGNATURE----- --=-Kn9FEVSnFqjqHl/x4Sr+-- From owner-linux-xfs@oss.sgi.com Wed Mar 3 16:17:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 16:17:05 -0800 (PST) Received: from mail.convergence.de (mail.convergence.de [212.84.236.4]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i240H0KO022110 for ; Wed, 3 Mar 2004 16:17:01 -0800 Received: from pd9e72e7b.dip.t-dialin.net ([217.231.46.123] helo=abc.local) by mail.convergence.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.30) id 1Ayfun-0001LC-Vv; Thu, 04 Mar 2004 00:36:38 +0100 Received: from js by abc.local with local (Exim 3.35 #1 (Debian)) id 1Ayfz6-0001AI-00; Thu, 04 Mar 2004 00:41:04 +0100 Date: Thu, 4 Mar 2004 00:41:04 +0100 From: Johannes Stezenbach To: Peter Nelson Cc: Hans Reiser , Jens Axboe , linux-kernel@vger.kernel.org, ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 Message-ID: <20040303234104.GD1875@convergence.de> Mail-Followup-To: Johannes Stezenbach , Peter Nelson , Hans Reiser , Jens Axboe , linux-kernel@vger.kernel.org, ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@oss.software.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com References: <4044119D.6050502@andrew.cmu.edu> <4044366B.3000405@namesys.com> <4044B787.7080301@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4044B787.7080301@andrew.cmu.edu> User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 2327 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: js@convergence.de Precedence: bulk X-list: linux-xfs Content-Length: 3033 Lines: 71 Peter Nelson wrote: > Hans Reiser wrote: > > >Are you sure your benchmark is large enough to not fit into memory, > >particularly the first stages of it? It looks like not. reiser4 is > >much faster on tasks like untarring enough files to not fit into ram, > >but (despite your words) your results seem to show us as slower unless > >I misread them.... > > I'm pretty sure most of the benchmarking I am doing fits into ram, > particularly because my system has 1GB of it, but I see this as > realistic. When I download a bunch of debs (or rpms or the kernel) I'm > probably going to install them directly with them still in the file > cache. Same with rebuilding the kernel after working on it. OK, that test is not very interesting for the FS gurus because it doesn't stress the disk enough. Anyway, I have some related questions concerning disk/fs performance: o I see you are using and IDE disk with a large (8MB) write cache. My understanding is that enabling write cache is a risky thing for journaled file systems, so for a fair comparison you would have to enable the write cache for ext2 and disable it for all journaled file systems. It would be nice if someone with more profound knowledge could comment on this, but my understanding of the problem is: - journaled filesystems can only work when they can enforce that journal data is written to the platters at specifc times wrt normal data writes - IDE write caching makes the disk "lie" to the kernel, i.e. it says "I've written the data" when it was only put in the cache - now if a *power failure* keeps the disk from writing the cache contents to the platter, the fs and journal are inconsistent (a kernel crash would not cause this problem because the disk can still write the cache contents to the platters) - at next mount time the fs will read the journal from the disk and try to use it to bring the fs into a consistent state; however, since the journal on disk is not guaranteed to be up to date this can *fail* (I have no idea what various fs implementations do to handle this; I suspect they at least refuse to mount and require you to manually run fsck. Or they don't notice and let you work with a corrupt filesystem until they blow up.) Right? Or is this just paranoia? To me it looks like IDE write barrier support (http://lwn.net/Articles/65353/) would be a way to safely enable IDE write caches for journaled filesystems. Has anyone done any benchmarks concerning write cache and journaling? o And one totally different :-) question: Has anyone benchmarked fs performance on PATA IDE disks vs. otherwise comparable SCSI or SATA disks (I vaguely recall having read that SATA has working TCQ, i.e. not broken by design as with PATA)? I have read a few times that SCSI disks perform much better than IDE disks. The usual reason given is "SCSI disks are built for servers, IDE for desktops". Is this all, or is it TCQ that matters? Or is the Linux SCSI core better than the IDE core? Johannes From owner-linux-xfs@oss.sgi.com Wed Mar 3 17:17:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 17:17:49 -0800 (PST) Received: from megachips.co.jp (ns.megachips.co.jp [211.12.79.195]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i241HiKO029067 for ; Wed, 3 Mar 2004 17:17:45 -0800 Received: from motooka2.megachips.co.jp (fw0.megachips.co.jp [172.16.79.194]) by megachips.co.jp (8.12.9/8.12.8) with SMTP id i241H49E051688; Thu, 4 Mar 2004 10:17:08 +0900 (JST) Message-Id: <200403040116.AA07168@motooka2.megachips.co.jp> From: Shigenori Motooka Date: Thu, 04 Mar 2004 10:16:59 +0900 To: Christoph Hellwig Cc: linux-xfs@oss.sgi.com, fujita.masahiro@megachips.co.jp, mase.hirohito@megachips.co.jp Subject: Re: question for xfs_repair and xfs_check In-Reply-To: <20040227112259.A31123@infradead.org> References: <20040227112259.A31123@infradead.org> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.12 Content-Type: text/plain; charset=us-ascii X-archive-position: 2328 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: motooka.shigenori@megachips.co.jp Precedence: bulk X-list: linux-xfs Content-Length: 3516 Lines: 86 Dear Christoph Hellwig , Thank you for your infomation. I found a reason for this problem. This problem is happend by lack of memory. "xfs_check" and "xfs_repaire" need too much memory. In our case (160GByte full disk), "xfs_check" and "xfs_repaire" request 100-400MByte memory. So, do you have any idea to reduce memory for "xfs_check" and "xfs_repaire" ?. Now, i am using xfs-cmd 2.3.5 version. More recent version is same condition. Also, is it possible to caluculate max memory ? Another quesion, I want to improve xfs performance (read,warite,delete). But, at this time,i can not kernel version(2.4.17),but it is possible to change code. Do you have any ideas to improve performance ? >As a simple addition: you could try to get newer XFS userspace from >oss.sgi.com - but 2.4.17 was before XFS 1.1 and thus has a slightly different >user <-> kernelspace api so it will probably not work. I still think it's >probably your kernel corrupting the filesystem and not a userspace issues, >though. Especially as powerpc is big endian and unsigned char - XFS was >written for such an enviroment (IRIX/mips) first but for the linux port >that combination has been broken a few times. > Shigenori Motooka MegaChips Corporation SYSTEM BUSINESS UNIT 4-1-6,Miyahara,Yodogawa-ku,Osaka,532-0003 JAPAN Phone:+81-6-6399-2865 Fax :+81-6-6399-6204 E-mail:motooka.shigenori@megachips.co.jp rom owner-linux-xfs@oss.sgi.com Wed Mar 3 17:36:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 17:36:30 -0800 (PST) Received: from gawab.com (www.gawab.com [204.97.230.36]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i241aPKO031899 for ; Wed, 3 Mar 2004 17:36:26 -0800 Received: (qmail 49529 invoked by uid 1004); 4 Mar 2004 01:41:15 -0000 Received: from unknown (HELO ramy) (ramy@62.114.196.145) by gawab.com with SMTP; 4 Mar 2004 01:41:15 -0000 From: "Ramy M. Hassan" To: Subject: Date: Thu, 4 Mar 2004 03:35:57 +0200 Message-ID: <000301c40189$0dde0d20$ba10a8c0@ramy> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 939 X-archive-position: 2329 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ramy@gawab.com Precedence: bulk X-list: linux-xfs Hi, I have about 1,000,000 directories currently stored on an ext3 partition. I want to move data to xfs. Due to ext3 limitations I apply a directory hashing algorithm to place those 1M directories into other subdirectories so that the maximum number of inodes in a directory does not exceed 32K ( ext3 limit ). I know that xfs does not have this limitation , and I read that it uses balanced trees to organize directories, but is it better in xfs to have all those 1M directories in a single flat level ( I never need to ls or readdir them all ) , or stick to balance them in three or four levels ? I also wonder if xfs performance is good for too many small files or not. I know it is the best for large files, but this is not my case ( my avarage file size is about 140k ) . If xfs is not the best choice for me , can you please suggest me a more suitable alternative. Best regards Ramy M. Hassan [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Mar 3 17:42:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 17:42:03 -0800 (PST) Received: from jdc.local (dyn172.mel2.homedsl.pacific.net.au [203.100.245.172]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i241fxKO000412 for ; Wed, 3 Mar 2004 17:42:00 -0800 Received: from jdc.local (localhost [127.0.0.1]) by jdc.local (8.12.11/8.12.11/Debian-1) with ESMTP id i241frBN001013 for ; Thu, 4 Mar 2004 12:41:53 +1100 Received: (from jason@localhost) by jdc.local (8.12.11/8.12.11/Debian-1) id i241frUV001006; Thu, 4 Mar 2004 12:41:53 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16454.35169.62744.399600@jdc.local> Date: Thu, 4 Mar 2004 12:41:53 +1100 To: linux-xfs Subject: XFS repair question X-Mailer: VM 7.18 under Emacs 21.3.1 Reply-To: jasonw@ariel.ucs.unimelb.edu.au X-archive-position: 2330 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonw@ariel.ucs.unimelb.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 615 Lines: 15 This morning my system spontaneously rebooted, possibly due to a power surge or similar problem, but I am not sure of the cause (there was nothing at all in the system log). After xfs recovery, with the main filesystem unmounted I ran xfs_repair, which fixed one disconnected inode and another inode with 0 link count. One of these inodes (as a file in /lost+found) contained data from the cups printer log, with the last entry dated 9 AM this morning (a couple of hours before the problem). There is no reason why the log would have been written to at the time of the reboot. Anything unusual or suspect here? From owner-linux-xfs@oss.sgi.com Wed Mar 3 17:46:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 17:46:57 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i241krKO001418 for ; Wed, 3 Mar 2004 17:46:54 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i241km02030169 for ; Wed, 3 Mar 2004 17:46:48 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i241klab34952811; Wed, 3 Mar 2004 19:46:47 -0600 (CST) Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i241klXa434996; Wed, 3 Mar 2004 19:46:47 -0600 (CST) Subject: Re: XFS repair question From: Russell Cattelan To: jasonw@ariel.ucs.unimelb.edu.au Cc: linux-xfs In-Reply-To: <16454.35169.62744.399600@jdc.local> References: <16454.35169.62744.399600@jdc.local> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-tvB78fsz2Fq6xcS9Jk+v" Message-Id: <1078364807.12279.21.camel@naboo.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5-4mdk Date: Wed, 03 Mar 2004 19:46:47 -0600 X-archive-position: 2331 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1231 Lines: 37 --=-tvB78fsz2Fq6xcS9Jk+v Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2004-03-03 at 19:41, Jason White wrote: > This morning my system spontaneously rebooted, possibly due to a power > surge or similar problem, but I am not sure of the cause (there was > nothing at all in the system log). >=20 > After xfs recovery, with the main filesystem unmounted I ran > xfs_repair, which fixed one disconnected inode and another inode with > 0 link count. >=20 > One of these inodes (as a file in /lost+found) contained data from the > cups printer log, with the last entry dated 9 AM this morning (a > couple of hours before the problem). There is no reason why the log > would have been written to at the time of the reboot. How old is you're XFS code? There was some syncing fixes in 1.3.0=20 >=20 > Anything unusual or suspect here? >=20 --=-tvB78fsz2Fq6xcS9Jk+v Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBARoqHNRmM+OaGhBgRAtMtAJ48v4tKX0j65M/lc05nyY4v0hJrQQCcDGds Ol3l1XgqpbCQ1kz2AkdzxDY= =HbA2 -----END PGP SIGNATURE----- --=-tvB78fsz2Fq6xcS9Jk+v-- From owner-linux-xfs@oss.sgi.com Wed Mar 3 18:05:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 18:05:22 -0800 (PST) Received: from jdc.local (dyn172.mel2.homedsl.pacific.net.au [203.100.245.172]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2425IKO003147 for ; Wed, 3 Mar 2004 18:05:19 -0800 Received: from jdc.local (localhost [127.0.0.1]) by jdc.local (8.12.11/8.12.11/Debian-1) with ESMTP id i2425CG1002684; Thu, 4 Mar 2004 13:05:12 +1100 Received: (from jason@localhost) by jdc.local (8.12.11/8.12.11/Debian-1) id i2425Cnh002676; Thu, 4 Mar 2004 13:05:12 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16454.36568.873845.910819@jdc.local> Date: Thu, 4 Mar 2004 13:05:12 +1100 To: Russell Cattelan Cc: linux-xfs Subject: Re: XFS repair question In-Reply-To: <1078364807.12279.21.camel@naboo.americas.sgi.com> References: <16454.35169.62744.399600@jdc.local> <1078364807.12279.21.camel@naboo.americas.sgi.com> X-Mailer: VM 7.18 under Emacs 21.3.1 Reply-To: jasonw@ariel.ucs.unimelb.edu.au X-archive-position: 2332 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonw@ariel.ucs.unimelb.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 501 Lines: 15 Russell Cattelan writes: > How old is you're XFS code? > There was some syncing fixes in 1.3.0 SGI-XFS CVS-2004-02-25_06:00_UTC with ACLs, security attributes, no debug enabled Linux version 2.6.3 (jason@jdc) (gcc version 3.3.3 (Debian)) #3 Thu Feb 26 21:20:50 EST 2004 Melbourne airport aviation weather is reporting 25-40 knot winds at the moment, and it certainly sounds that way outside the house, so I wouldn't be surprised if the unexpected reboot were due to problems with a power line. From owner-linux-xfs@oss.sgi.com Wed Mar 3 22:07:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Mar 2004 22:07:28 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2467HKO028566 for ; Wed, 3 Mar 2004 22:07:17 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2467AP8021721 for ; Thu, 4 Mar 2004 00:07:11 -0600 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA26690; Thu, 4 Mar 2004 17:07:07 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i24675Fx009033; Thu, 4 Mar 2004 17:07:06 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i2466pJ3002212; Thu, 4 Mar 2004 17:06:52 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i2466pCv002210; Thu, 4 Mar 2004 17:06:51 +1100 Date: Thu, 4 Mar 2004 17:06:50 +1100 From: Nathan Scott To: Jason White Cc: linux-xfs Subject: Re: XFS repair question Message-ID: <20040304060650.GA2030@frodo> References: <16454.35169.62744.399600@jdc.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16454.35169.62744.399600@jdc.local> User-Agent: Mutt/1.5.3i X-archive-position: 2333 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1000 Lines: 27 On Thu, Mar 04, 2004 at 12:41:53PM +1100, Jason White wrote: > This morning my system spontaneously rebooted, possibly due to a power > surge or similar problem, but I am not sure of the cause (there was > nothing at all in the system log). > > After xfs recovery, with the main filesystem unmounted I ran > xfs_repair, which fixed one disconnected inode and another inode with > 0 link count. > > One of these inodes (as a file in /lost+found) contained data from the > cups printer log, with the last entry dated 9 AM this morning (a > couple of hours before the problem). There is no reason why the log > would have been written to at the time of the reboot. > > Anything unusual or suspect here? Given your kernel version, it sounds alot like theres a kernel bug lurking in there somewhere, we'll need to try to reproduce and address that. Was there anything unusual about that file? (if its still there in lost+found, could you send me the xfs_db dump of that inode?) thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Mar 4 01:29:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Mar 2004 01:29:26 -0800 (PST) Received: from p15104972.pureserver.info (kettenhemdhuehner.de [217.160.131.79]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i249T1KO017223 for ; Thu, 4 Mar 2004 01:29:02 -0800 Received: from lxkris.int.cinetic.de (grossetto.cinetic.de [217.72.192.194]) (authenticated bits=0) by p15104972.pureserver.info (8.12.6/8.12.6/SuSE Linux 0.6) with ESMTP id i249S741016307 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 4 Mar 2004 10:28:07 +0100 From: Kristian =?iso-8859-15?q?K=F6hntopp?= To: Felipe Alfaro Solana , Robin Rosenberg Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 Date: Thu, 4 Mar 2004 10:28:07 +0100 User-Agent: KMail/1.5.4 Cc: David Weinehall , Andrew Ho , Dax Kelson , Peter Nelson , Hans Reiser , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com References: <4044119D.6050502@andrew.cmu.edu> <200403031059.26483.robin.rosenberg.lists@dewire.com> <1078309141.863.3.camel@teapot.felipe-alfaro.com> In-Reply-To: <1078309141.863.3.camel@teapot.felipe-alfaro.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200403041028.07235.kris@koehntopp.de> X-archive-position: 2334 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kris@koehntopp.de Precedence: bulk X-list: linux-xfs Content-Length: 1341 Lines: 26 On Wednesday 03 March 2004 11:19, Felipe Alfaro Solana wrote: > The problem is that I couldn't save anything: the XFS volume refused to > mount and the XFS recovery tools refused to fix anything. It was just a > single disk bad block. For example in ext2/3 critical parts are > replicated several times over the volume, so there's minimal chance of > being unable to mount the volume and recover important files. That is a misconception. What is being replicated multiple times in ext2 is the superblock and the block group descriptors. But these are not really needed for recovery (as long as they have default values, which is the case in the vast majority of installations). What is not being replicated is the block allocation bitmap, inode allocation bitmap and the inodes themselves. By running "mke2fs -S" on a ext2 file system, you will rewrite all superblocks, all block group descriptors, and all allocation bitmaps, but leave the inodes themselves intact. You can recreate the filesystem from that with e2fsck, proving that the information from the replicated parts of the file systems is not really necessary. All that e2fsck needs to recover the system is the information from the inodes. If they are damaged (and they are not replicated), the files having inodes in damaged blocks cannot be recovered. Kristian From owner-linux-xfs@oss.sgi.com Thu Mar 4 03:19:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Mar 2004 03:19:10 -0800 (PST) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i24BJ5KO003288 for ; Thu, 4 Mar 2004 03:19:05 -0800 Received: from [192.168.10.75] (c-24-98-62-33.atl.client2.attbi.com[24.98.62.33]) by comcast.net (rwcrmhc11) with SMTP id <20040303224437013002u5dge>; Wed, 3 Mar 2004 22:44:37 +0000 Subject: Re: 2.4.25 & xfs & ide write barriers From: Danny Cox To: Michael Lampe Cc: Jeremy Jackson , XFS Mailing List In-Reply-To: <40436E6A.5020800@iwr.uni-heidelberg.de> References: <403E0A7A.3040505@iwr.uni-heidelberg.de> <20040229221924.GA731@frodo> <4043355E.9080208@iwr.uni-heidelberg.de> <40435121.4050906@coplanar.net> <40436E6A.5020800@iwr.uni-heidelberg.de> Content-Type: text/plain Organization: No Organization at ALL Message-Id: <1078353875.25678.30.camel@pip> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 03 Mar 2004 17:44:35 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2335 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: danscox@mindspring.com Precedence: bulk X-list: linux-xfs Content-Length: 631 Lines: 25 Jeremy & Michael, On Mon, 2004-03-01 at 12:10, Michael Lampe wrote: > Jeremy Jackson wrote: > > > SCSI disks > > use TCQ to achieve write performance without compromising data > > integrity. > > Ordered queue tags can be used to implement write barriers. > > > (XFS guys - Linux does this, right?) > > No. (I'm not an XFS guy, though.) Actually, the answer is: "not yet". There is extant code, but the controllers and disks that can actually make use of it is rather thin right now (in the ATA camp). -- kernel, n.: A part of an operating system that preserves the medieval traditions of sorcery and black art. Danny From owner-linux-xfs@oss.sgi.com Thu Mar 4 07:07:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Mar 2004 07:08:00 -0800 (PST) Received: from guanin.uni-konstanz.de (guanin.uni-konstanz.de [134.34.240.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i24F7SKO018008 for ; Thu, 4 Mar 2004 07:07:29 -0800 Received: from viribus.rz.uni-konstanz.de (viribus.rz.uni-konstanz.de [134.34.240.50]) by guanin.uni-konstanz.de (Postfix) with ESMTP id 26D6726BC14; Thu, 4 Mar 2004 15:37:49 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by localhost.viribus.rz.uni-konstanz.de (Postfix) with ESMTP id 0FB8E1F8007; Thu, 4 Mar 2004 15:37:49 +0100 (CET) Received: from localhost (taxis.rz.uni-konstanz.de [134.34.3.51]) by viribus.rz.uni-konstanz.de (Postfix) with ESMTP id 9F1B51F8003; Thu, 4 Mar 2004 15:37:47 +0100 (CET) Received: from 193.96.192.155 ([193.96.192.155]) by webmail.uni-konstanz.de (IMP) with HTTP for ; Thu, 4 Mar 2004 15:37:47 +0100 Message-ID: <1078411067.40473f3b6b835@webmail.uni-konstanz.de> Date: Thu, 4 Mar 2004 15:37:47 +0100 From: Pascal Gienger To: Felipe Alfaro Solana Cc: Robin Rosenberg , David Weinehall , Andrew Ho , Dax Kelson , Peter Nelson , Hans Reiser , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com Subject: Re: [Jfs-discussion] Re: Desktop Filesystem Benchmarks in 2.6.3 References: <4044119D.6050502@andrew.cmu.edu> <40453538.8050103@animezone.org> <20040303014115.GP19111@khan.acc.umu.se> <200403030700.57164.robin.rosenberg.lists@dewire.com> <1078307033.904.1.camel@teapot.felipe-alfaro.com> In-Reply-To: <1078307033.904.1.camel@teapot.felipe-alfaro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 193.96.192.155 X-Virus-Scanned: by amavisd-new at Mailservice RZ Uni-Konstanz Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i24F7dKO018018 X-archive-position: 2336 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pascal.gienger@uni-konstanz.de Precedence: bulk X-list: linux-xfs Content-Length: 524 Lines: 18 Quoting Felipe Alfaro Solana : > But XFS easily breaks down due to media defects. Once ago I used > XFS, > but I lost all data on one of my volumes due to a bad block on my > hard > disk. XFS was unable to recover from the error, and the XFS recovery > tools were unable to deal with the error. 1. How long ago is "Once ago"? Did you report that to the xfs developers? 2. Speaking for servers, we live in a RAID and/or SAN-world. The media error issue is a non-issue. Just my $0.02, Pascal From owner-linux-xfs@oss.sgi.com Thu Mar 4 08:28:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Mar 2004 08:28:10 -0800 (PST) Received: from strike.wu-wien.ac.at (strike.wu-wien.ac.at [137.208.8.200]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i24GS4KO030975 for ; Thu, 4 Mar 2004 08:28:05 -0800 Received: from strike.wu-wien.ac.at (ariel.wu-wien.ac.at [137.208.89.100]) by strike.wu-wien.ac.at (8.11.6/8.11.6) with ESMTP id i24GRtd29281; Thu, 4 Mar 2004 17:27:55 +0100 Message-ID: <4047590D.5030904@strike.wu-wien.ac.at> Date: Thu, 04 Mar 2004 17:27:57 +0100 From: Alexander Bergolth User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031115 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs + lvm on software raid5 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2337 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: leo@strike.wu-wien.ac.at Precedence: bulk X-list: linux-xfs Content-Length: 3273 Lines: 103 Hi! I'd like to create a xfs-formatted filesystem in an lvm logical volume that resides on a software raid5 device. Searching the list archives, I've found that performance should be ok using an internal log for kernel versions > 2.4.18. Additionally, I found a recommendation to use log version 2. However, when creating the filesystem, the kernel reports that the cache buffer size is reduced to 512 bytes: # mkfs.xfs -l version=2 /dev/vg_raid5/lv_images raid5: switching cache buffer size, 1024 --> 512 Are there additional arguments needed for mkfs.xfs? The first reduction of cache buffer size occurs when activating lvm: LVM version 1.0.7(28/03/2003) module loaded loop: loaded (max 8 devices) raid5: switching cache buffer size, 4096 --> 1024 Does this mean a performance penalty? Is there a way to avoid these switches? Is it still recommended to use an external log? How should the log be configured? Thanks in advance, --leo P.S.: Additional info: # cat /etc/fedora-release Fedora Core release 1 (Yarrow) # uname -r 2.4.22-1.2115.nptl_22.rhfc1.at # rpm -q xfsprogs xfsprogs-2.6.2-0_7.rhfc1.at # cat /proc/mdstat Personalities : [raid5] read_ahead 1024 sectors md0 : active raid5 hdg1[0] hdi1[1] hdk1[2] hdm1[3] hdo1[4] 976751616 blocks level 5, 32k chunk, algorithm 2 [5/5] [UUUUU] # mkfs.xfs -l version=2 /dev/vg_raid5/lv_images meta-data=/dev/vg_raid5/lv_images isize=256 agcount=16, agsize=8192000 blks = sectsz=512 data = bsize=4096 blocks=131072000, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768, version=2 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 # pvdisplay /dev/md0 --- Physical volume --- PV Name /dev/md0 VG Name vg_raid5 PV Size 931.50 GB [1953503232 secs] / NOT usable 64.19 MB [LVM: 186 KB] PV# 1 PV Status available Allocatable yes Cur LV 1 PE Size (KByte) 65536 Total PE 14903 Free PE 6903 Allocated PE 8000 PV UUID d63Tg4-A41Z-4JXb-FwuV-wIik-QuVh-k2XW7E # vgdisplay /dev/vg_raid5 --- Volume group --- VG Name vg_raid5 VG Access read/write VG Status available/resizable VG # 0 MAX LV 256 Cur LV 1 Open LV 0 MAX LV Size 2 TB Max PV 256 Cur PV 1 Act PV 1 VG Size 931.44 GB PE Size 64 MB Total PE 14903 Alloc PE / Size 8000 / 500 GB Free PE / Size 6903 / 431.44 GB VG UUID 1f13FE-qPVM-1CSB-0gAu-Fe07-5TlS-ElliwA -- ----------------------------------------------------------------------- Alexander (Leo) Bergolth leo@leo.wu-wien.ac.at WU-Wien - Zentrum fuer Informatikdienste http://leo.wu-wien.ac.at Computers are like air conditioners - they stop working properly when you open Windows From owner-linux-xfs@oss.sgi.com Thu Mar 4 13:31:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Mar 2004 13:31:50 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i24LVmKO024357 for ; Thu, 4 Mar 2004 13:31:48 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i24LVmN5024356 for linux-xfs@oss.sgi.com; Thu, 4 Mar 2004 13:31:48 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i24LVjKQ024332 for ; Thu, 4 Mar 2004 13:31:45 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i24Kd6CZ010371; Thu, 4 Mar 2004 12:39:06 -0800 Date: Thu, 4 Mar 2004 12:39:06 -0800 Message-Id: <200403042039.i24Kd6CZ010371@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 313] New: xfs_log_write: reservation ran out. Need to up reservation X-Bugzilla-Reason: AssignedTo X-archive-position: 2338 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1433 Lines: 37 http://oss.sgi.com/bugzilla/show_bug.cgi?id=313 Summary: xfs_log_write: reservation ran out. Need to up reservation Product: Linux XFS Version: unspecified Platform: IA32 OS/Version: Linux Status: NEW Severity: major Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: akp@cohaesio.com Tried 2.6.4-rc2 on an XFS/NFS server, and shortly after mounting the XFS filesystem (~700 GB), the kernel logged the following: Mar 4 20:50:10 db1 kernel: Filesystem "sdc1": xfs_log_write: reservation ran out. Need to up reservation Mar 4 20:50:10 db1 kernel: xfs_force_shutdown(sdc1,0x8) called from line 1693 of file fs/xfs/xfs_log.c. Return address = 0xc0219676 Mar 4 20:50:10 db1 kernel: Filesystem "sdc1": Corruption of in-memory data detected. Shutting down filesystem: sdc1 Mar 4 20:50:10 db1 kernel: Please umount the filesystem, and rectify the problem(s) Mar 4 20:50:10 db1 kernel: xfs_force_shutdown(sdc1,0x2) called from line 1291 of file fs/xfs/xfs_log.c. Return address = 0xc0219676 Further details about the setup (dmesg and kernel log) as well as previous problems are available at http://oss.sgi.com/bugzilla/show_bug.cgi?id=309 . ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 4 14:18:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Mar 2004 14:18:18 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i24MIEKO031352 for ; Thu, 4 Mar 2004 14:18:15 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i24LBm2N029130 for ; Thu, 4 Mar 2004 13:11:49 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA09125; Fri, 5 Mar 2004 09:09:51 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i24M9nFx028038; Fri, 5 Mar 2004 09:09:50 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i24M9Y87000791; Fri, 5 Mar 2004 09:09:35 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i24M9XOE000789; Fri, 5 Mar 2004 09:09:33 +1100 Date: Fri, 5 Mar 2004 09:09:33 +1100 From: Nathan Scott To: Alexander Bergolth Cc: linux-xfs@oss.sgi.com Subject: Re: xfs + lvm on software raid5 Message-ID: <20040304220933.GB661@frodo> References: <4047590D.5030904@strike.wu-wien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4047590D.5030904@strike.wu-wien.ac.at> User-Agent: Mutt/1.5.3i X-archive-position: 2339 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 857 Lines: 30 On Thu, Mar 04, 2004 at 05:27:57PM +0100, Alexander Bergolth wrote: > Hi! > > I'd like to create a xfs-formatted filesystem in an lvm logical volume > that resides on a software raid5 device. > > Searching the list archives, I've found that performance should be ok > using an internal log for kernel versions > 2.4.18. Additionally, I > found a recommendation to use log version 2. > > However, when creating the filesystem, the kernel reports that the cache > buffer size is reduced to 512 bytes: > > # mkfs.xfs -l version=2 /dev/vg_raid5/lv_images > raid5: switching cache buffer size, 1024 --> 512 > > Are there additional arguments needed for mkfs.xfs? Try instead mkfs.xfs -ssize=4k /dev/vg_raid5/lv_images > Does this mean a performance penalty? Is there a way to avoid these > switches? Above option should do so. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Mar 4 14:31:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Mar 2004 14:31:49 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i24MVlKO000957 for ; Thu, 4 Mar 2004 14:31:47 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i24MVl9R000956 for linux-xfs@oss.sgi.com; Thu, 4 Mar 2004 14:31:47 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i24MVjKQ000941 for ; Thu, 4 Mar 2004 14:31:46 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i24Llub6026371; Thu, 4 Mar 2004 13:47:56 -0800 Date: Thu, 4 Mar 2004 13:47:56 -0800 Message-Id: <200403042147.i24Llub6026371@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 313] xfs_log_write: reservation ran out. Need to up reservation X-Bugzilla-Reason: AssignedTo X-archive-position: 2340 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 378 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=313 ------- Additional Comments From nathans@sgi.com 2004-04-03 13:47 PDT ------- hi there, Could you add the xfs_info output for this filesystem, and any mount options you were using at the time. thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 4 15:31:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Mar 2004 15:31:51 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i24NVmKO010640 for ; Thu, 4 Mar 2004 15:31:48 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i24NVmLX010639 for linux-xfs@oss.sgi.com; Thu, 4 Mar 2004 15:31:48 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i24NVkKQ010613 for ; Thu, 4 Mar 2004 15:31:46 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i24Mnrxk003601; Thu, 4 Mar 2004 14:49:53 -0800 Date: Thu, 4 Mar 2004 14:49:53 -0800 Message-Id: <200403042249.i24Mnrxk003601@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 313] xfs_log_write: reservation ran out. Need to up reservation X-Bugzilla-Reason: AssignedTo X-archive-position: 2341 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 894 Lines: 25 http://oss.sgi.com/bugzilla/show_bug.cgi?id=313 ------- Additional Comments From akp@cohaesio.com 2004-04-03 14:49 PDT ------- [root@db1 root]# mount | grep xfs /dev/sdc1 on /mnt/data1 type xfs (rw,noatime,usrquota) [root@db1 root]# xfs_info /mnt/data1 meta-data=/mnt/data1 isize=256 agcount=171, agsize=1048576 blks = sectsz=512 data = bsize=4096 blocks=179216391, imaxpct=25 = sunit=2 swidth=12 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=2 = sectsz=512 sunit=2 blks realtime =none extsz=65536 blocks=0, rtextents=0 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 4 17:33:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Mar 2004 17:33:18 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i251XAKO028170 for ; Thu, 4 Mar 2004 17:33:11 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i251X5fk017652 for ; Thu, 4 Mar 2004 19:33:05 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i251X4Ke35016863; Thu, 4 Mar 2004 19:33:04 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i251X3Er1250078; Thu, 4 Mar 2004 19:33:04 -0600 (CST) Date: Thu, 4 Mar 2004 19:33:03 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Frank Hellmann cc: XFS List Subject: Re: XFS on large block device problem In-Reply-To: <403F1F47.7040003@opticalart.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2342 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3217 Lines: 93 Frank, see this thread on lkml - this should at least get you going. http://www.ussg.iu.edu/hypermail/linux/kernel/0403.0/0820.html The changes should make it into 2.6.4 I think. -Eric On Fri, 27 Feb 2004, Frank Hellmann wrote: > Hi Eric! > > Eric Sandeen wrote: > > If you are able to re-mkfs the filesystem, can you try a mkfs > > immediately followed by a repair, to see if the mkfs worked properly? > > I've been talking to someone else on 2.6.3 + xfs + lbd + md where mkfs > > wasn't even able to get bits down to the disk properly. This is just > > userspace; if we can't do writes and have md put them in the right > > place, we're in trouble. stracing mkfs, I see pwrites of superblocks to > > locations that never seem to make it to disk... I'm tempted to blame > > md, but I need to try to recreate here. > > > > Anyway, can you try mkfs.xfs; xfs_repair? > > Sure. > > I did a clean run of the mkfs.xfs and two runs of xfs_repair. > > It seems that the xfs_repair doesn't like the filesystem that much. > > I attached the output and strace. > > > I was wondering if using the other LVM methods would help here? I will > give the dm stuff a try and let you know, if it's just dependend on md. > > Cheers, > Frank... > > > > > -Eric > > > > On Thu, 2004-02-26 at 11:58, Frank Hellmann wrote: > > > >>Hi! > >> > >>I just upgraded one of our linux boxes (Redhat 9 + usual 2.6 and glibc > >>patches) to kernel 2.6.3 and wanted to try out the large block device > >>support. First attemp, beware... :-) > >> > >>I setup a md0 device consisting of four ~1.5TB large devices with mkraid > >>/dev/md0 and a simple /etc/raidtab. > >> > >>I had some issues makeing the filesystem on /dev/md0. mkfs.xfs > >>complained about a non-clean md0 device and would not let me do anything > >>with it. > >> > >>Upgrading to xfs-progs 2.6.3 and mdadm 1.5 tools didn't change that. > >> > >>First doing an mkfs.ext3, mounting and unmounting the device seems to > >>cure that. At least after that I could mkfs.xfs it. > >> > >>Unfortunatly restoring (tar not xfsrestore) some demo data back onto the > >>drive I was getting a lot of xfs/kernel messages into the logfile. The > >>tar process stopped with errors after about 200M of restore and the last > >>files got corrupted. pdflush has high activity (~95%). > >> > >>xfs_repair reports beside a lot of other problems a couple of: > >> > >>primary/secondary superblock XX conflict - AG superblock geometry info > >>conflicts with filesystem geometry > >> > >>which really makes me wonder, whats going on... See the attached files > >>for further info. Unfortunatly I currently don't have any debugging > >>tools on that machine... > >> > >>Everything is peachy (with LBD), if I stay below the usual 2TB limits > >>with the 2.6.3 kernel. > >> > >>Am I missing anything for XFS LBD support? Any ideas? > >> > >> > >> Cheers, > >> Frank... > > -- > -------------------------------------------------------------------------- > Frank Hellmann Optical Art GmbH Waterloohain 7a > Digital Cinema http://www.opticalart.de 22769 Hamburg > frank@opticalart.de Tel: ++49 40 5111051 Fax: ++49 40 43169199 > From owner-linux-xfs@oss.sgi.com Thu Mar 4 17:53:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Mar 2004 17:53:30 -0800 (PST) Received: from ariel.ucs.unimelb.edu.au (ariel.ucs.unimelb.edu.au [128.250.20.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i251r9KO030563 for ; Thu, 4 Mar 2004 17:53:10 -0800 Received: from ariel.ucs.unimelb.edu.au (localhost [127.0.0.1]) by ariel.ucs.unimelb.edu.au (8.12.10/8.12.8) with ESMTP id i251r822016583; Fri, 5 Mar 2004 12:53:08 +1100 (EST) Received: from localhost (jasonw@localhost) by ariel.ucs.unimelb.edu.au (8.12.10/8.12.3) with ESMTP id i251r7MY016579; Fri, 5 Mar 2004 12:53:07 +1100 (EST) Date: Fri, 5 Mar 2004 12:53:07 +1100 (EST) From: Jason White To: Nathan Scott cc: linux-xfs Subject: Re: XFS repair question In-Reply-To: <20040304060650.GA2030@frodo> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2343 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonw@ariel.ucs.unimelb.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 815 Lines: 23 On Thu, 4 Mar 2004, Nathan Scott wrote: > > Given your kernel version, it sounds alot like theres a kernel > bug lurking in there somewhere, we'll need to try to reproduce > and address that. Was there anything unusual about that file? > (if its still there in lost+found, could you send me the xfs_db > dump of that inode?) To confirm: I can do this with the file system mounted, xfs_db -r then inode nnnn (where nnnn is the inode number) print I will also try to track down whether there was a cron job active around the time of the crash that may have moved or deleted the file. I didn't notice anything unusual about the file itself - just an ordinary log file with entries going back several days. The second inode placed in lost+found was empty; for completeness I will send you the dump of that too. From owner-linux-xfs@oss.sgi.com Thu Mar 4 17:56:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Mar 2004 17:57:02 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i251uwKO031250 for ; Thu, 4 Mar 2004 17:56:59 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i251uqfk025351 for ; Thu, 4 Mar 2004 19:56:52 -0600 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA12500; Fri, 5 Mar 2004 12:56:50 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i251umFx033178; Fri, 5 Mar 2004 12:56:49 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i251uX87001440; Fri, 5 Mar 2004 12:56:33 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i251uW3K001438; Fri, 5 Mar 2004 12:56:32 +1100 Date: Fri, 5 Mar 2004 12:56:32 +1100 From: Nathan Scott To: Jason White Cc: linux-xfs Subject: Re: XFS repair question Message-ID: <20040305015632.GC990@frodo> References: <20040304060650.GA2030@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 2344 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 989 Lines: 27 On Fri, Mar 05, 2004 at 12:53:07PM +1100, Jason White wrote: > On Thu, 4 Mar 2004, Nathan Scott wrote: > > > > Given your kernel version, it sounds alot like theres a kernel > > bug lurking in there somewhere, we'll need to try to reproduce > > and address that. Was there anything unusual about that file? > > (if its still there in lost+found, could you send me the xfs_db > > dump of that inode?) > > To confirm: I can do this with the file system mounted, xfs_db -r > then inode nnnn (where nnnn is the inode number) > print Its not a good idea to do this while mounted in 2.6 atm. > I will also try to track down whether there was a cron job active around > the time of the crash that may have moved or deleted the file. I didn't > notice anything unusual about the file itself - just an ordinary log file > with entries going back several days. The second inode placed in > lost+found was empty; for completeness I will send you the dump of that > too. OK, thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Mar 4 19:23:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Mar 2004 19:23:24 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i253NLKO008151 for ; Thu, 4 Mar 2004 19:23:21 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i253NEfk018952 for ; Thu, 4 Mar 2004 21:23:15 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i253N8AL893130; Fri, 5 Mar 2004 14:23:08 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i253N7wt894032; Fri, 5 Mar 2004 14:23:07 +1100 (EST) Date: Fri, 5 Mar 2004 14:23:07 +1100 (EST) From: Nathan Scott Message-Id: <200403050323.i253N7wt894032@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 910702 - deadlock fix X-archive-position: 2345 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 394 Lines: 14 Fix a 2.6-specific out-of-space deadlock when flushing delalloc data with pages locked under write. Deja vu. Date: Thu Mar 4 19:22:11 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux Inspected by: sandeen@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:167948a linux-2.6/xfs_super.c - 1.297 From owner-linux-xfs@oss.sgi.com Thu Mar 4 20:00:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Mar 2004 20:00:48 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2540kKO012126 for ; Thu, 4 Mar 2004 20:00:46 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2540cfk030772 for ; Thu, 4 Mar 2004 22:00:39 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2540WAL943865; Fri, 5 Mar 2004 15:00:32 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2540VmZ943407; Fri, 5 Mar 2004 15:00:31 +1100 (EST) Date: Fri, 5 Mar 2004 15:00:31 +1100 (EST) From: Nathan Scott Message-Id: <200403050400.i2540VmZ943407@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 910624 - fsync tuning X-archive-position: 2346 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 464 Lines: 17 Remove dup fdatasync/fdatawait call on fsync. Means we no longer take the iolock here, and hence readers no longer conflict with concurrent fsync activity. Kudos to Steve! Date: Thu Mar 4 19:58:57 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux Inspected by: lord@xfs.org,felixb@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:167949a xfs_vnodeops.c - 1.621 From owner-linux-xfs@oss.sgi.com Thu Mar 4 20:10:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Mar 2004 20:10:17 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i254AFKO013323 for ; Thu, 4 Mar 2004 20:10:15 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i253C4hE016565 for ; Thu, 4 Mar 2004 19:12:05 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i254A5AL954325; Fri, 5 Mar 2004 15:10:05 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i254A38n952797; Fri, 5 Mar 2004 15:10:03 +1100 (EST) Date: Fri, 5 Mar 2004 15:10:03 +1100 (EST) From: Nathan Scott Message-Id: <200403050410.i254A38n952797@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 907752 - xfs_io X-archive-position: 2347 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 649 Lines: 25 xfs_io(8) changes to allow some operations to work on non-XFS files (blkdev, etc). Date: Thu Mar 4 20:08:55 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:167950a xfsprogs/man/man8/xfs_io.8 - 1.2 xfsprogs/io/command.c - 1.4 xfsprogs/io/command.h - 1.5 xfsprogs/io/pread.c - 1.10 xfsprogs/io/truncate.c - 1.6 xfsprogs/io/quit.c - 1.4 xfsprogs/io/pwrite.c - 1.10 xfsprogs/io/help.c - 1.4 xfsprogs/io/init.h - 1.4 xfsprogs/io/open.c - 1.10 xfsprogs/io/init.c - 1.6 xfsprogs/io/fsync.c - 1.4 From owner-linux-xfs@oss.sgi.com Thu Mar 4 20:19:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Mar 2004 20:19:06 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i254J4KO014785 for ; Thu, 4 Mar 2004 20:19:04 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i253FrhE016986 for ; Thu, 4 Mar 2004 19:15:54 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i254DsAL958349; Fri, 5 Mar 2004 15:13:54 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i254DrjU958141; Fri, 5 Mar 2004 15:13:53 +1100 (EST) Date: Fri, 5 Mar 2004 15:13:53 +1100 (EST) From: Nathan Scott Message-Id: <200403050413.i254DrjU958141@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 910637 - fix up libuuid check X-archive-position: 2348 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 406 Lines: 16 Fix xfsprogs builds on certain platforms with unusual libuuid locations. Date: Thu Mar 4 20:12:55 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:167951a xfsprogs/configure.in - 1.30 xfsprogs/m4/package_uuiddev.m4 - 1.6 xfsprogs/aclocal.m4 - 1.7 From owner-linux-xfs@oss.sgi.com Thu Mar 4 20:33:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Mar 2004 20:33:15 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i254XBKO019459 for ; Thu, 4 Mar 2004 20:33:12 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i254X4fk008548 for ; Thu, 4 Mar 2004 22:33:05 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i254X0AL980461; Fri, 5 Mar 2004 15:33:00 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i254WxgV980435; Fri, 5 Mar 2004 15:32:59 +1100 (EST) Date: Fri, 5 Mar 2004 15:32:59 +1100 (EST) From: Nathan Scott Message-Id: <200403050432.i254WxgV980435@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 910636 - mkfs uses O_EXCL X-archive-position: 2349 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 551 Lines: 18 Enable use of O_EXCL in mkfs, for exclusive 2.6 blockdev access. This will give "mostly harmless" 8^) warnings in 2.6.early, but more recent versions will do the right thing always (2.6.4 and onward will not warn). Date: Thu Mar 4 20:26:40 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:167952a xfsprogs/mkfs/xfs_mkfs.c - 1.54 xfsprogs/include/libxfs.h - 1.34 xfsprogs/libxfs/init.c - 1.35 From owner-linux-xfs@oss.sgi.com Thu Mar 4 20:35:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Mar 2004 20:35:30 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i254ZRKO020203 for ; Thu, 4 Mar 2004 20:35:27 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i254ZKfk009381 for ; Thu, 4 Mar 2004 22:35:21 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i254ZJAL976472 for ; Fri, 5 Mar 2004 15:35:20 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i254ZJTB984317 for linux-xfs@oss.sgi.com; Fri, 5 Mar 2004 15:35:19 +1100 (EST) Date: Fri, 5 Mar 2004 15:35:19 +1100 (EST) From: Nathan Scott Message-Id: <200403050435.i254ZJTB984317@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs X-archive-position: 2350 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 386 Lines: 15 Bump xfsprogs version number for recent batch of updates. Date: Thu Mar 4 20:34:58 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:167953a xfsprogs/VERSION - 1.100 xfsprogs/doc/CHANGES - 1.137 xfsprogs/debian/changelog - 1.90 From owner-linux-xfs@oss.sgi.com Thu Mar 4 22:31:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Mar 2004 22:32:01 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i256VnKO029782 for ; Thu, 4 Mar 2004 22:31:49 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i256VnED029781 for linux-xfs@oss.sgi.com; Thu, 4 Mar 2004 22:31:49 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i256VlKQ029767 for ; Thu, 4 Mar 2004 22:31:47 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i255mo0d027328; Thu, 4 Mar 2004 21:48:50 -0800 Date: Thu, 4 Mar 2004 21:48:50 -0800 Message-Id: <200403050548.i255mo0d027328@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 313] xfs_log_write: reservation ran out. Need to up reservation X-Bugzilla-Reason: AssignedTo X-archive-position: 2351 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 6358 Lines: 195 http://oss.sgi.com/bugzilla/show_bug.cgi?id=313 ------- Additional Comments From nathans@sgi.com 2004-04-03 21:48 PDT ------- Ah, a version 2 log. Apparently this was a known problem with version 2 logs, and some recent fixes have made it more likely to trigger -- Tim's working on the fix as we speak. I'd reassign to Tim, but he doesn't have an account yet... let me go get that fixed up. cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. rom owner-linux-xfs@oss.sgi.com Fri Mar 5 00:16:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Mar 2004 00:16:31 -0800 (PST) Received: from jdc.local (dyn172.mel2.homedsl.pacific.net.au [203.100.245.172]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i258GMKO004706 for ; Fri, 5 Mar 2004 00:16:23 -0800 Received: from jdc.local (localhost [127.0.0.1]) by jdc.local (8.12.11/8.12.11/Debian-1) with ESMTP id i258GFrD001530; Fri, 5 Mar 2004 19:16:15 +1100 Received: (from jason@localhost) by jdc.local (8.12.11/8.12.11/Debian-1) id i258GF6Z001522; Fri, 5 Mar 2004 19:16:15 +1100 From: Jason White MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0X5GFMO5LD" Content-Transfer-Encoding: 7bit Message-ID: <16456.14159.666929.920105@jdc.local> Date: Fri, 5 Mar 2004 19:16:15 +1100 To: Nathan Scott Cc: linux-xfs Subject: Re: XFS repair question In-Reply-To: <20040304060650.GA2030@frodo> References: <16454.35169.62744.399600@jdc.local> <20040304060650.GA2030@frodo> X-Mailer: VM 7.18 under Emacs 21.3.1 Reply-To: jasonw@ariel.ucs.unimelb.edu.au X-archive-position: 2352 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonw@ariel.ucs.unimelb.edu.au Precedence: bulk X-list: linux-xfs --0X5GFMO5LD Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Nathan Scott writes: > (if its still there in lost+found, could you send me the xfs_db > dump of that inode?) Attached. I would be pleased to provide any other information that may help the XFS developers. I like to contribute to the free software I use, even if only by reporting bugs. --0X5GFMO5LD Content-Type: text/plain Content-Description: xfs_db output Content-Disposition: inline; filename="xfs_debug_output" Content-Transfer-Encoding: 7bit xfs_db> inode 71364872 xfs_db> print core.magic = 0x494e core.mode = 0100644 core.version = 1 core.format = 2 (extents) core.nlinkv1 = 1 core.uid = 0 core.gid = 106 core.flushiter = 90 core.atime.sec = Fri Mar 5 18:44:52 2004 core.atime.nsec = 544233856 core.mtime.sec = Thu Mar 4 09:23:44 2004 core.mtime.nsec = 873774156 core.ctime.sec = Thu Mar 4 09:23:44 2004 core.ctime.nsec = 873774156 core.size = 9360 core.nblocks = 3 core.extsize = 0 core.nextents = 2 core.naextents = 0 core.forkoff = 0 core.aformat = 2 (extents) core.dmevmask = 0 core.dmstate = 0 core.newrtbm = 0 core.prealloc = 0 core.realtime = 0 core.immutable = 0 core.append = 0 core.sync = 0 core.noatime = 0 core.nodump = 0 core.gen = 21 next_unlinked = null u.bmx[0-1] = [startoff,startblock,blockcount,extentflag] 0:[0,4460471,1,0] 1:[1,4465620,2,0] xfs_db> inode 75557802 xfs_db> p core.magic = 0x494e core.mode = 0100600 core.version = 1 core.format = 2 (extents) core.nlinkv1 = 1 core.uid = 0 core.gid = 0 core.flushiter = 0 core.atime.sec = Wed Jan 7 22:31:26 2004 core.atime.nsec = 891393000 core.mtime.sec = Wed Jan 7 22:20:54 2004 core.mtime.nsec = 433354000 core.ctime.sec = Wed Jan 7 22:31:26 2004 core.ctime.nsec = 891500000 core.size = 0 core.nblocks = 0 core.extsize = 0 core.nextents = 0 core.naextents = 0 core.forkoff = 0 core.aformat = 2 (extents) core.dmevmask = 0 core.dmstate = 0 core.newrtbm = 0 core.prealloc = 0 core.realtime = 0 core.immutable = 0 core.append = 0 core.sync = 0 core.noatime = 0 core.nodump = 0 core.gen = 751 next_unlinked = null u = (empty) xfs_db> quit --0X5GFMO5LD Content-Type: application/gzip Content-Description: contents of lost+found Content-Disposition: attachment; filename="inodes.tar.gz" Content-Transfer-Encoding: base64 H4sIAH81SEACA+2aW2+cRhTH/exPMfKLE6Vm5z4DkqVGiaokSiureaqqPrCA vSQYCJfa7qfvYNYO4OzODNhNUs2R5UUL53eG+Z8zFxZv5a1+Pguv3yRhnFQH T2JQGYcQwN6mnxBzfH/cf4845ghcHPwH1tZNWKkmVkXR7LsuL9ZFfLP/Joc3 d/DtbdynX46H1zAIPrx68/b9H16VZElYJ6ddfwDksZBw8Czlkp+U0UmW5u31 yUXePj/E/M4jrKJNc1Mmp9e3nXhIxd2Zv4tsE1de3F6WcdgkpwgKSQVFCHlC IuIj1YxDzCaXq4+8OEWHBE5OrLMi+lSn/ySnGB4eOHtE876D+kfkK/UvOLh2 9f/k9a9qLWzSy/sShVR6jCFBJOGwq8To/izhhHHpScwY6Tjd2cvdZ11t/Qi2 yoq6eXFetHm8eso8FIztrP/uWM0IGDG1FOB39Q8Bc/W/yLo+xZBgNunfXfoL RDiVAj/J+E/pSHfE7sZ8rGzbPqrGjl5/QZD6/J70z8owvkzzH1r/bf8Or3kL /oRk9WtYrTCENIB+wHiAEXiBlMdf4H1aN0me5hegKQAMOEGHOo9CLSRiEBX5 eXrRVmpyKXJwnmYJOFolTbSK2rK+/Rd73TVHOt6rLUgxz4sKtGXXEnUGRFma 5E3t6QAvs6y46u5g6tq1MU+iroE1KJMKbFQpaHG/tFkG1FpZ3SZIa3X0uU1V 43b54WG/nJ29rgPwu1pqDTujLOPaU8vko58AYqC7xvMscL8VIE+ugOqbaBPm F6qf9iPo1+4kKi7LLGmSrzrJgNzH/RBtkrjNVG/Vm7Zpun6Ni6sc5EV1GWbZ zQMA4so7UEsF44x64LEwo6Y864yaAhZm1BRnmlFbP/RIGbUbZ5xRWwSxyqjO iQXw3ullHHd92Q3DDViHqgMrUIYXSt28yJOjroc/FmvApDBFJXm8EPSuvw58 bpNW3b7Kt2O1BQ2zk7JK8yapjsH6Bhx/LDb5sZb1obuxLtfSTHmCVVtXqyxd 90r1X67KuinKGjw7e/saSMaf3yamaWPvAqzD6FN36+MI229XZVip+kyyuyBC H0T9CWuVpClKp5Ie1KskZ6s0ZNmqhNRGadiD0jiCjUwqiq+P4gcQW+vkm6J0 OulBvU7+bJ2GLGud1Opy2IO+cQQrnTAmJlEotNXJh6YojU4GoHf9dQt0+sKy 1onIYT0ZtHaWTkT62igUzpidfGSK0umkB/U6obk6jVjWOjEKhz2IjCNY6cQo 0kdRSw/fWidsitLppAf1OuHZOg1Z1jpxf1RP2DiClU7c9/VRSICktU7EFKXT SQ/qdSKzdRqyrHWSbFRPxDiClU6SIZMolFvrRE1ROp30oF4nukCnLyxbnRRk OMMbtHaOTh1IH4UOngPY78dlANGg7A3241OPpfvxCc9+Pz4BLN2PT3DG+/Fb Pwofaz++E2e+H+8R2G4/rpxIQOxHaGaK0lW+HtRXPptX+ROWbeX7PhuWJDMO YFP4vs/1QWgAmbVK3BSlU0kP6lXis1UasqznUTTajxu0dtY8ikb78Z1RGJo9 PmMYUBkwaj4+P/BYOD5Pedbj8xSwcHye4kzH560fe6TxeTfOeHzeIoTV+IyR mu4Dwu0yio4e4SM2AOzIqH0eczJqD88so/YA5mTUHtzejHroJ5ZklBFuf0Y9 RPj6jJo4iWF9ms4lwhSlm0v0oH4usXgCv4dl/wR+tFkSxgHsnsBjfRA54wm8 L01ROpX0oF4lOVulJU92JRtN+NI4gJ1KvkkQYv9c1zdF6VTSg3qV/AUq0dnP oSQfLWx94wBWKnGhDYKHP1QaqsQhNEXtV8kE9K6/bq5KI5b9r1nD53gmrZ23 eoZQH4UEFFktVcYey5cqI96cpcoIsHypMsJZLFU6P/x4S5UdOJulSofQvH7i 3sj8du9/CsaYkPBp3v/b8/737bEQggvOOOa37/9hgb6v9/9+xPe/+z4VEHEw PHZZ78yZM2fOnDlz5syZM2fOnDlz5syZM2fOnDlz5szZ/9P+BUDL6wsAUAAA --0X5GFMO5LD-- From owner-linux-xfs@oss.sgi.com Fri Mar 5 01:08:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Mar 2004 01:08:35 -0800 (PST) Received: from jdc.local (dyn172.mel2.homedsl.pacific.net.au [203.100.245.172]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2598UKO008839 for ; Fri, 5 Mar 2004 01:08:31 -0800 Received: from jdc.local (localhost [127.0.0.1]) by jdc.local (8.12.11/8.12.11/Debian-1) with ESMTP id i2598Ouh003408 for ; Fri, 5 Mar 2004 20:08:24 +1100 Received: (from jason@localhost) by jdc.local (8.12.11/8.12.11/Debian-1) id i2598OI2003401; Fri, 5 Mar 2004 20:08:24 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16456.17288.393283.302537@jdc.local> Date: Fri, 5 Mar 2004 20:08:24 +1100 To: linux-xfs Subject: Re: XFS repair question In-Reply-To: <20040305015632.GC990@frodo> References: <20040304060650.GA2030@frodo> <20040305015632.GC990@frodo> X-Mailer: VM 7.18 under Emacs 21.3.1 Reply-To: jasonw@ariel.ucs.unimelb.edu.au X-archive-position: 2353 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonw@ariel.ucs.unimelb.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 1748 Lines: 80 My reply to Nathan bounced when sent to the list, possibly due to the attachments. For the benefit of everyone else on the list, and the archive, here is the debug output. xfs_db> inode 71364872 xfs_db> print core.magic = 0x494e core.mode = 0100644 core.version = 1 core.format = 2 (extents) core.nlinkv1 = 1 core.uid = 0 core.gid = 106 core.flushiter = 90 core.atime.sec = Fri Mar 5 18:44:52 2004 core.atime.nsec = 544233856 core.mtime.sec = Thu Mar 4 09:23:44 2004 core.mtime.nsec = 873774156 core.ctime.sec = Thu Mar 4 09:23:44 2004 core.ctime.nsec = 873774156 core.size = 9360 core.nblocks = 3 core.extsize = 0 core.nextents = 2 core.naextents = 0 core.forkoff = 0 core.aformat = 2 (extents) core.dmevmask = 0 core.dmstate = 0 core.newrtbm = 0 core.prealloc = 0 core.realtime = 0 core.immutable = 0 core.append = 0 core.sync = 0 core.noatime = 0 core.nodump = 0 core.gen = 21 next_unlinked = null u.bmx[0-1] = [startoff,startblock,blockcount,extentflag] 0:[0,4460471,1,0] 1:[1,4465620,2,0] xfs_db> inode 75557802 xfs_db> p core.magic = 0x494e core.mode = 0100600 core.version = 1 core.format = 2 (extents) core.nlinkv1 = 1 core.uid = 0 core.gid = 0 core.flushiter = 0 core.atime.sec = Wed Jan 7 22:31:26 2004 core.atime.nsec = 891393000 core.mtime.sec = Wed Jan 7 22:20:54 2004 core.mtime.nsec = 433354000 core.ctime.sec = Wed Jan 7 22:31:26 2004 core.ctime.nsec = 891500000 core.size = 0 core.nblocks = 0 core.extsize = 0 core.nextents = 0 core.naextents = 0 core.forkoff = 0 core.aformat = 2 (extents) core.dmevmask = 0 core.dmstate = 0 core.newrtbm = 0 core.prealloc = 0 core.realtime = 0 core.immutable = 0 core.append = 0 core.sync = 0 core.noatime = 0 core.nodump = 0 core.gen = 751 next_unlinked = null u = (empty) xfs_db> quit From owner-linux-xfs@oss.sgi.com Fri Mar 5 02:20:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Mar 2004 02:20:55 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i25AKoKO011552 for ; Fri, 5 Mar 2004 02:20:51 -0800 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AzCRk-0001Kd-00 for ; Fri, 05 Mar 2004 11:20:48 +0100 Received: from nfsd.linpro.no ([80.232.36.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Mar 2004 11:20:48 +0100 Received: from perbu by nfsd.linpro.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Mar 2004 11:20:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: Per Andreas Buer Subject: Re: [Jfs-discussion] Re: Desktop Filesystem Benchmarks in 2.6.3 Date: Thu, 04 Mar 2004 21:43:44 +0100 Organization: - Message-ID: References: <4044119D.6050502@andrew.cmu.edu> <40453538.8050103@animezone.org> <20040303014115.GP19111@khan.acc.umu.se> <200403030700.57164.robin.rosenberg.lists@dewire.com> <1078307033.904.1.camel@teapot.felipe-alfaro.com> <1078411067.40473f3b6b835@webmail.uni-konstanz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: nfsd.linpro.no User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) Cancel-Lock: sha1:luoBCwtb7BbeF7Jayc3TnI6bGw8= Cc: linux-kernel@vger.kernel.org, ext2-devel@sourceforge.net, Ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com Cc: linux-kernel@vger.kernel.org, ext2-devel@sourceforge.net, Ext3-users@redhat.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org, Ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com X-archive-position: 2354 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: perbu@linpro.no Precedence: bulk X-list: linux-xfs Content-Length: 402 Lines: 11 Pascal Gienger writes: > 2. Speaking for servers, we live in a RAID and/or SAN-world. The media > error issue is a non-issue. If your cooling system stops you will experience media errors. A filesystem which detects this halts the kernel really helps. -- There are only 10 different kinds of people in the world, those who understand binary, and those who don't. From owner-linux-xfs@oss.sgi.com Fri Mar 5 03:59:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Mar 2004 04:00:03 -0800 (PST) Received: from server7.nfra.nl (server7.nfra.nl [192.87.1.57]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i25BxvKO015730 for ; Fri, 5 Mar 2004 03:59:58 -0800 Received: from wop10.nfra.nl [195.169.63.130] by server7.nfra.nl; Fri, 05 Mar 2004 13:01:09 +0100 Date: Fri, 5 Mar 2004 11:59:49 +0000 (UTC) From: Ramesh K X-X-Sender: kram@wop10.nfra.nl To: linux-xfs@oss.sgi.com Subject: realtime subvolumes, again! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2355 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kram@astron.nl Precedence: bulk X-list: linux-xfs Content-Length: 1750 Lines: 39 Hello, I finally managed to get realtime subvolumes working in my system. I built a new kernel using the sources at SGI (Kernel 2.4.25). I have also been testing the realtime subvolumes with my application. The application writes data to a XFS realtime subvolume at 80 MBytes/sec. I'm using 3ware Raid Controller 7810, configured as RAID 0 with 64K stripes. The man page of mk.xfs says, "the real-time extent size should be carefully chosen to match the parameters of the physical media used" - can someone say more about this? What more do I need to know about the ophysical media? Here's the output generated by xfs_info: /******************************************************/ kram@dop93:~> xfs_info /data meta-data=/data isize=256 agcount=25, agsize=1048576 blks = sectsz=512 data = bsize=4096 blocks=25601577, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=12500, version=1 = sectsz=512 sunit=0 blks realtime =external extsz=65536 blocks=208836967, rtextents=13052310 /****************************************************/ The RAID controller document says that smaller stripe width is more suited for sequential access, and that is what I do. I use preallocated files in realtime subvolume. What I see is the disk-pack exhibits some sort of sponginess with time. Is it entirely due to the RAID Controller + harddisk combination, or is it something from XFS realtime subvolumes? I can include some statistics of the latencies if you need. Thank you. Regards Ramesh From owner-linux-xfs@oss.sgi.com Fri Mar 5 05:42:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Mar 2004 05:42:44 -0800 (PST) Received: from foo.ardendo.se (foo.ardendo.se [212.32.189.9]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i25DgZKO022465 for ; Fri, 5 Mar 2004 05:42:36 -0800 Received: from localhost (localhost [127.0.0.1]) by foo.ardendo.se (Postfix) with ESMTP id 4033C239BA; Thu, 4 Mar 2004 10:35:55 +0100 (CET) Subject: Re: Filesystem kernel hangup, 2.6.3 (bad: scheduling while atomic!) From: Mikael Wahlberg To: Christoph Hellwig Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Per Lejontand , Jonas =?ISO-8859-1?Q?Engstr=F6m?= In-Reply-To: <20040223131331.A8778@infradead.org> References: <20040222164941.D6046@foo.ardendo.se> <20040223121959.A8354@infradead.org> <1077541689.1247.12.camel@harrier> <20040223131331.A8778@infradead.org> Content-Type: text/plain Organization: Ardendo Message-Id: <1078392951.643.6.camel@harrier> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 04 Mar 2004 10:35:52 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 2356 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mikael.wahlberg@ardendo.se Precedence: bulk X-list: linux-xfs Content-Length: 7821 Lines: 155 On Mon, 2004-02-23 at 14:13, Christoph Hellwig wrote: > On Mon, Feb 23, 2004 at 02:08:09PM +0100, Mikael Wahlberg wrote: > > If you need any more information please tell us, it is quite urgent for > > us, since we really don't want to go back to 2.4, the performance > > increase with 2.6 is really impressive (Except when it crashes :) > > Can you check whether the small patch below gets rid of you problems? > It still wouldn't explain the JFS problems, though. > > --- 1.59/fs/xfs/linux/xfs_aops.c Mon Feb 9 05:39:27 2004 > +++ edited/fs/xfs/linux/xfs_aops.c Mon Feb 23 15:11:33 2004 > @@ -1170,7 +1170,7 @@ > if (!delalloc && !unwritten) > goto free_buffers; > > - if (!(gfp_mask & __GFP_FS)) > + if ((gfp_mask & (__GFP_FS|__GFP_WAIT)) != (__GFP_FS|__GFP_WAIT)) > return 0; > > /* If we are already inside a transaction or the thread cannot Unfortunately yesterday evening during peak load we got another filesystem hang, the oops looks like below: We feel a bit sad to have do downgrade to a 2.4 kernel, with the performance loss that would imply. So any ideas would be very helpful. Mar 3 18:27:35 c-serv kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000 Mar 3 18:27:35 c-serv kernel: printing eip: Mar 3 18:27:36 c-serv kernel: c025c9a2 Mar 3 18:27:36 c-serv kernel: *pde = 00000000 Mar 3 18:27:36 c-serv kernel: Oops: 0000 [#1] Mar 3 18:27:36 c-serv kernel: CPU: 0 Mar 3 18:27:36 c-serv kernel: EIP: 0060:[] Not tainted Mar 3 18:27:36 c-serv kernel: EFLAGS: 00010206 Mar 3 18:27:36 c-serv kernel: EIP is at _pagebuf_find+0xd2/0x2c0 Mar 3 18:27:37 c-serv kernel: eax: 7930e000 ebx: 00000000 ecx: 7930e187 edx: 0003f000 Mar 3 18:27:37 c-serv kernel: esi: 00000000 edi: f63a5260 ebp: c04cd068 esp: c6897b94 Mar 3 18:27:37 c-serv kernel: ds: 007b es: 007b ss: 0068 Mar 3 18:27:37 c-serv kernel: Process proftpd (pid: 15349, threadinfo=c6896000 task=d479b900) Mar 3 18:27:37 c-serv kernel: Stack: f7fe2740 0003f000 00000008 00000000 c02098c8 f638ae50 0000008e 0003f000 Mar 3 18:27:37 c-serv kernel: 00000008 c0e84980 0080003f 040001f8 0000a005 c025cc75 f7942fc0 040001f8 Mar 3 18:27:37 c-serv kernel: 00000000 00001000 0000a005 c0e84980 040001f8 00000000 0000a005 0080003f Mar 3 18:27:37 c-serv kernel: Call Trace: Mar 3 18:27:37 c-serv kernel: [] xfs_bmapi_single+0xf8/0x1c0 Mar 3 18:27:37 c-serv kernel: [] pagebuf_get+0xa5/0x180 Mar 3 18:27:37 c-serv kernel: [] xfs_trans_read_buf+0x32f/0x390 Mar 3 18:27:37 c-serv kernel: [] xfs_da_do_buf+0x7ef/0x9e0 Mar 3 18:27:37 c-serv kernel: [] nf_hook_slow+0xf7/0x160 Mar 3 18:27:37 c-serv kernel: [] xfs_da_read_buf+0x57/0x60 Mar 3 18:27:37 c-serv kernel: [] xfs_da_node_lookup_int+0x8c/0x390 Mar 3 18:27:37 c-serv kernel: [] xfs_da_node_lookup_int+0x8c/0x390 Mar 3 18:27:37 c-serv kernel: [] xfs_dir2_node_lookup+0x3f/0xc0 Mar 3 18:27:37 c-serv kernel: [] xfs_dir2_lookup+0x13f/0x150 Mar 3 18:27:37 c-serv kernel: [] ext3_journal_dirty_data+0x0/0x70 Mar 3 18:27:37 c-serv kernel: [] memcpy_toiovec+0x5c/0x90 Mar 3 18:27:37 c-serv kernel: [] xfs_dir_lookup_int+0x4c/0x130 Mar 3 18:27:37 c-serv kernel: [] xfs_lookup+0x65/0x90 Mar 3 18:27:37 c-serv kernel: [] linvfs_lookup+0x67/0xa0 Mar 3 18:27:38 c-serv kernel: [] real_lookup+0xcf/0x100 Mar 3 18:27:38 c-serv kernel: [] do_lookup+0xa6/0xc0 Mar 3 18:27:38 c-serv kernel: [] link_path_walk+0x573/0xad0 Mar 3 18:27:38 c-serv kernel: [] locks_delete_lock+0x8b/0xf0 Mar 3 18:27:38 c-serv kernel: [] __posix_lock_file+0x435/0x660 Mar 3 18:27:38 c-serv kernel: [] __user_walk+0x49/0x60 Mar 3 18:27:38 c-serv kernel: [] vfs_lstat+0x1c/0x60 Mar 3 18:27:38 c-serv kernel: [] fcntl_setlk64+0x11d/0x2c0 Mar 3 18:27:38 c-serv kernel: [] del_timer_sync+0x38/0x140 Mar 3 18:27:38 c-serv kernel: [] sys_lstat64+0x1b/0x40 Mar 3 18:27:38 c-serv kernel: [] sys_fcntl64+0x57/0xa0 Mar 3 18:27:38 c-serv kernel: [] syscall_call+0x7/0xb Mar 3 18:27:38 c-serv kernel: Mar 3 18:27:38 c-serv kernel: Code: 8b 1b 0f 18 03 90 39 ee 75 e4 8b 5c 24 4c 85 db 0f 84 85 00 Mar 3 18:27:38 c-serv kernel: <6>note: proftpd[15349] exited with preempt_count 1 Mar 3 18:27:38 c-serv kernel: bad: scheduling while atomic! Mar 3 18:27:38 c-serv kernel: Call Trace: Mar 3 18:27:38 c-serv kernel: [] schedule+0x6ee/0x700 Mar 3 18:27:38 c-serv kernel: [] zap_pmd_range+0x4b/0x70 Mar 3 18:27:38 c-serv kernel: [] free_pages_and_swap_cache+0x6a/0xa0 Mar 3 18:27:38 c-serv kernel: [] unmap_vmas+0x23c/0x2f0 Mar 3 18:27:38 c-serv kernel: [] exit_mmap+0xf4/0x250 Mar 3 18:27:39 c-serv kernel: [] mmput+0x6d/0xa0 Mar 3 18:27:39 c-serv kernel: [] do_exit+0x1a3/0x500 Mar 3 18:27:39 c-serv kernel: [] die+0xfc/0x100 Mar 3 18:27:39 c-serv kernel: [] do_page_fault+0x1f9/0x523 Mar 3 18:27:39 c-serv kernel: [] process_backlog+0x81/0x120 Mar 3 18:27:39 c-serv kernel: [] net_rx_action+0xe4/0x130 Mar 3 18:27:39 c-serv kernel: [] do_IRQ+0x15d/0x1d0 Mar 3 18:27:39 c-serv kernel: [] do_page_fault+0x0/0x523 Mar 3 18:27:39 c-serv kernel: [] error_code+0x2d/0x38 Mar 3 18:27:39 c-serv kernel: [] _pagebuf_find+0xd2/0x2c0 Mar 3 18:27:39 c-serv kernel: [] xfs_bmapi_single+0xf8/0x1c0 Mar 3 18:27:39 c-serv kernel: [] pagebuf_get+0xa5/0x180 Mar 3 18:27:39 c-serv kernel: [] xfs_trans_read_buf+0x32f/0x390 Mar 3 18:27:39 c-serv kernel: [] xfs_da_do_buf+0x7ef/0x9e0 Mar 3 18:27:39 c-serv kernel: [] nf_hook_slow+0xf7/0x160 Mar 3 18:27:39 c-serv kernel: [] xfs_da_read_buf+0x57/0x60 Mar 3 18:27:39 c-serv kernel: [] xfs_da_node_lookup_int+0x8c/0x390 Mar 3 18:27:39 c-serv kernel: [] xfs_da_node_lookup_int+0x8c/0x390 Mar 3 18:27:40 c-serv kernel: [] xfs_dir2_node_lookup+0x3f/0xc0 Mar 3 18:27:40 c-serv kernel: [] xfs_dir2_lookup+0x13f/0x150 Mar 3 18:27:40 c-serv kernel: [] ext3_journal_dirty_data+0x0/0x70 Mar 3 18:27:40 c-serv kernel: [] memcpy_toiovec+0x5c/0x90 Mar 3 18:27:40 c-serv kernel: [] xfs_dir_lookup_int+0x4c/0x130 Mar 3 18:27:40 c-serv kernel: [] xfs_lookup+0x65/0x90 Mar 3 18:27:40 c-serv kernel: [] linvfs_lookup+0x67/0xa0 Mar 3 18:27:40 c-serv kernel: [] real_lookup+0xcf/0x100 Mar 3 18:27:40 c-serv kernel: [] do_lookup+0xa6/0xc0 Mar 3 18:27:40 c-serv kernel: [] link_path_walk+0x573/0xad0 Mar 3 18:27:40 c-serv kernel: [] locks_delete_lock+0x8b/0xf0 Mar 3 18:27:40 c-serv kernel: [] __posix_lock_file+0x435/0x660 Mar 3 18:27:40 c-serv kernel: [] __user_walk+0x49/0x60 Mar 3 18:27:40 c-serv kernel: [] vfs_lstat+0x1c/0x60 Mar 3 18:27:40 c-serv kernel: [] fcntl_setlk64+0x11d/0x2c0 Mar 3 18:27:40 c-serv kernel: [] del_timer_sync+0x38/0x140 Mar 3 18:27:40 c-serv kernel: [] sys_lstat64+0x1b/0x40 Mar 3 18:27:40 c-serv kernel: [] sys_fcntl64+0x57/0xa0 Mar 3 18:27:40 c-serv kernel: [] syscall_call+0x7/0xb Mar 3 18:27:40 c-serv kernel: /Mikael -- ----------------------------------------------------------------------- Mikael Wahlberg, M.Sc. Ardendo Unit Manager Professional Services/ e-mail: mikael@ardendo.se Technical Project Manager GSM: +46 733 279 274 From owner-linux-xfs@oss.sgi.com Fri Mar 5 07:35:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Mar 2004 07:35:31 -0800 (PST) Received: from stargate.coplanar.net (root@CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.112.162.124]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i25FZSKO027290 for ; Fri, 5 Mar 2004 07:35:28 -0800 Received: from coplanar.net (thunderdome.skynet.coplanar.net [192.168.7.3]) (authenticated bits=0) by stargate.coplanar.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id i25FZDp9004637 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 5 Mar 2004 10:35:20 -0500 Message-ID: <40489E2B.6000503@coplanar.net> Date: Fri, 05 Mar 2004 10:35:07 -0500 From: Jeremy Jackson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: XFS Linux Subject: oops report 2.4.23 smp 586 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (stargate.coplanar.net: domain of jerj@coplanar.net designates 192.168.7.3 as SASL permitted sender) X-archive-position: 2357 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 4045 Lines: 102 Hi, If anyone is interested furthur details can be forwarded. This happened on my mail server after 30 days uptime. XFS is SGI XFS snapshot-2.4.23-2003-12-01_00:33_UTC with ACLs, debug enabled SGI XFS Quota Management subsystem procmail processes started to accumulate stuck in lock_wait, had to reboot. Mar 4 17:13:41 dmz kernel: __alloc_pages: 4-order allocation failed (gfp=0xf0/0) Mar 4 17:13:45 dmz last message repeated 6 times ....... Mar 4 18:32:25 dmz kernel: XFS assertion failed: xfs_bmbt_disk_get_startoff(r1) + xfs_bmbt_disk_get_blockcount(r1) <= xfs_bmbt_disk_get_startoff(r2), file: xfs_btree.c, line: 287 partly decoded oops: ksymoops 2.4.5 on i686 2.4.23-jerj1-k7-smp. Options used -v /data/build/packages/kernel-image-2.4-i386/build-686-smp/vmlinux (specified) -K (specified) -L (specified) -o /lib/modules/2.4.23-jerj1-686-smp/kernel/ (specified) -m /boot/System.map-2.4.23-jerj1-686-smp (specified) -S -i No modules in ksyms, skipping objects kernel BUG at debug.c:55! invalid operand: 0000 CPU: 1 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 00000098 ebx: 206970c4 ecx: 00000046 edx: 00000001 esi: 00186884 edi: c1b44fe8 ebp: c16a2018 esp: c10d9b00 ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 5, stackpage=c10d9000) Stack: c03a3700 c03923a0 c0391f70 0000011f c01c398d c03923a0 c0391f70 0000011f c1b44fe8 c16a2018 c16a2018 000000fe c01bdde4 00000002 c1b44fe8 c16a2018 00000000 00000000 00000000 c14d4440 c16a2fe8 00011eee 00000001 c1b44fe8 [] xfs_btree_check_rec+0x149/0x154 [kernel] [] xfs_bmap_check_leaf_extents+0x310/0x484 [kernel] [] xfs_bmap_add_extent+0x521/0x538 [kernel] [] xfs_bmapi+0x9bd/0x1654 [kernel] [] xfs_bmap_search_extents+0x4c/0x54 [kernel] [] xfs_iomap_write_allocate+0x27f/0x410 [kernel] [] kfree_skbmem+0xc/0x68 [kernel] [] locate_hd_struct+0x29/0x74 [kernel] [] xfs_iomap+0x281/0x454 [kernel] [] xfs_iunlock+0x1d9/0x1e0 [kernel] [] xfs_iomap+0x39b/0x454 [kernel] [] xfs_bmap+0xa1/0xa8 [kernel] [] map_blocks+0x79/0xd4 [kernel] [] page_state_convert+0x279/0x50c [kernel] [] linvfs_release_page+0x52/0x6c [kernel] [] try_to_release_page+0x33/0x50 [kernel] [] shrink_cache+0x232/0x424 [kernel] [] shrink_caches+0x3c/0x48 [kernel] [] try_to_free_pages_zone+0x5c/0xe8 [kernel] [] kswapd_balance_pgdat+0x56/0xa4 [kernel] [] kswapd_balance+0x1e/0x34 [kernel] [] kswapd+0x99/0xb4 [kernel] [] arch_kernel_thread+0x28/0x38 [kernel] Code: 0f 0b 37 00 2e 37 3a c0 83 c4 10 c3 8d 76 00 53 8b 1d a0 b4 >>EIP; c021d6d9 <===== >>ebx; 206970c4 Before first symbol >>esi; 00186884 Before first symbol >>edi; c1b44fe8 >>ebp; c16a2018 >>esp; c10d9b00 Code; c021d6d9 00000000 <_EIP>: Code; c021d6d9 0: 0f 0b ud2a <===== Code; c021d6db 2: 37 aaa Code; c021d6dc 3: 00 2e add %ch,(%esi) Code; c021d6de 5: 37 aaa Code; c021d6df 6: 3a c0 cmp %al,%al Code; c021d6e1 8: 83 c4 10 add $0x10,%esp Code; c021d6e4 b: c3 ret Code; c021d6e5 c: 8d 76 00 lea 0x0(%esi),%esi Code; c021d6e8 f: 53 push %ebx Code; c021d6e9 10: 8b 1d a0 b4 00 00 mov 0xb4a0,%ebx From owner-linux-xfs@oss.sgi.com Fri Mar 5 08:30:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Mar 2004 08:30:38 -0800 (PST) Received: from localhost.localdomain ([63.81.117.28]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i25GUZKO031761 for ; Fri, 5 Mar 2004 08:30:36 -0800 Received: from xfs.org (jen [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i25GQoTo003048; Fri, 5 Mar 2004 10:26:53 -0600 Message-ID: <4048AA4A.2000705@xfs.org> Date: Fri, 05 Mar 2004 10:26:50 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeremy Jackson CC: XFS Linux Subject: Re: oops report 2.4.23 smp 586 References: <40489E2B.6000503@coplanar.net> In-Reply-To: <40489E2B.6000503@coplanar.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2358 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1158 Lines: 34 Jeremy Jackson wrote: > Hi, > > If anyone is interested furthur details can be forwarded. > > This happened on my mail server after 30 days uptime. XFS is > SGI XFS snapshot-2.4.23-2003-12-01_00:33_UTC with ACLs, debug enabled > SGI XFS Quota Management subsystem > > procmail processes started to accumulate stuck in lock_wait, had to reboot. > > Mar 4 17:13:41 dmz kernel: __alloc_pages: 4-order allocation failed > (gfp=0xf0/0) > Mar 4 17:13:45 dmz last message repeated 6 times > ....... > Mar 4 18:32:25 dmz kernel: XFS assertion failed: > xfs_bmbt_disk_get_startoff(r1) + xfs_bmbt_disk_get_blockcount(r1) <= > xfs_bmbt_disk_get_startoff(r2), file: xfs_btree.c, line: 287 > > partly decoded oops: > Just as an aside, running with debug enabled means that you are absolutely crippling xfs performance, debug is really a developer tool, not a production use flag. It did however point to exactly where in the code it went belly up, in a function which only exists when debug is turned on to check the layout of some data structures. I would run xfs_check on the filesystem and then xfs_repair, send the output of both to the list. Steve From owner-linux-xfs@oss.sgi.com Fri Mar 5 09:23:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Mar 2004 09:23:09 -0800 (PST) Received: from ns1.tippett.com (user-112vvgq.biz.mindspring.com [66.47.254.26]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i25HN2KO000677 for ; Fri, 5 Mar 2004 09:23:05 -0800 Received: from hermes.tippett.com (hermes-e.tippett.com [192.168.3.20]) by ns1.tippett.com (8.12.8/8.12.8) with ESMTP id i25HDWpE004754 for ; Fri, 5 Mar 2004 09:13:33 -0800 Received: from tippett.com (gangsta.tippett.com [192.168.3.62]) by hermes.tippett.com (980427.SGI.8.8.8/8.7.3) with ESMTP id JAA54190 for ; Fri, 5 Mar 2004 09:22:44 -0800 (PST) Message-ID: <4048B764.306@tippett.com> Date: Fri, 05 Mar 2004 09:22:44 -0800 From: Christian Rice Organization: Tippett Studio User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: why can't I make 2.6 kernels boot xfs? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 X-archive-position: 2359 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xian@tippett.com Precedence: bulk X-list: linux-xfs Content-Length: 1156 Lines: 34 I've looked everywhere for a clue as to where I'm screwing up, but I've not figured this out. For some reason, starting with 2.6.x, I can't get the kernels I build to mount the root partition. It's kind of driving me batty, because I KNOW I have XFS and IDE support NAILED in the kernel, not as modules. I get a VFS Panic every time along the lines of: VFS: Cannot open root device hda3 or "hda3" Please append a correct "root=" boot option grub.conf: title Red Hat Linux (2.6.3) root (hd0,0) kernel /vmlinuz-2.6.3 root=303 mem=nopentium idebus=66 initrd /initrd-2.6.3.img I've been building successful XFS kernels for a couple years, using them on HUNDREDS of production workstations, servers and renderfarm machines. This 2.6 business is confuscating. Basically, I'm just downloading the kernel source from www.kernel.org, adding Tronds NFS_All patches, if any, and building the kernel with gcc 3.2.2. No deja searches yield answers that help. Everyone says "make sure you've turned on IDE support, blah blah. It's on. Any help yielding the bootable condition will earn my undying gratitude. Thanks. From owner-linux-xfs@oss.sgi.com Fri Mar 5 09:31:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Mar 2004 09:31:04 -0800 (PST) Received: from mail.pacrimopen.com ([64.65.177.98]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i25HV1KO001328 for ; Fri, 5 Mar 2004 09:31:01 -0800 Received: from mail.pacrimopen.com (localhost [127.0.0.1]) by mail.pacrimopen.com (Postfix) with ESMTP id C497770007A6; Fri, 5 Mar 2004 09:33:16 -0800 (PST) Received: from UNKNOWN(127.0.0.1), claiming to be "mail.pacrimopen.com" via SMTP by sa-relay.pacrimopen.com, id smtpdzLTX1b; Fri Mar 5 09:33:11 2004 Received: from bubbles.imr-net.com (unknown [12.111.175.170]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pacrimopen.com (Postfix) with ESMTP id 3497070007A6; Fri, 5 Mar 2004 09:33:11 -0800 (PST) Subject: Re: why can't I make 2.6 kernels boot xfs? From: Joshua Schmidlkofer To: Christian Rice Cc: XFS List In-Reply-To: <4048B764.306@tippett.com> References: <4048B764.306@tippett.com> Content-Type: text/plain Message-Id: <1078507506.9724.12.camel@bubbles.imr-net.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 05 Mar 2004 09:25:07 -0800 Content-Transfer-Encoding: 7bit X-archive-position: 2360 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: menion@asylumwear.com Precedence: bulk X-list: linux-xfs Content-Length: 2141 Lines: 64 On Fri, 2004-03-05 at 09:22, Christian Rice wrote: > I've looked everywhere for a clue as to where I'm screwing up, but I've > not figured this out. > > For some reason, starting with 2.6.x, I can't get the kernels I build to > mount the root partition. It's kind of driving me batty, because I KNOW > I have XFS and IDE support NAILED in the kernel, not as modules. > > I get a VFS Panic every time along the lines of: > > VFS: Cannot open root device hda3 or "hda3" > Please append a correct "root=" boot option > > grub.conf: > > title Red Hat Linux (2.6.3) > root (hd0,0) > kernel /vmlinuz-2.6.3 root=303 mem=nopentium idebus=66 > initrd /initrd-2.6.3.img > > > > I've been building successful XFS kernels for a couple years, using them > on HUNDREDS of production workstations, servers and renderfarm > machines. This 2.6 business is confuscating. Basically, I'm just > downloading the kernel source from www.kernel.org, adding Tronds NFS_All > patches, if any, and building the kernel with gcc 3.2.2. > > No deja searches yield answers that help. Everyone says "make sure > you've turned on IDE support, blah blah. It's on. > > Any help yielding the bootable condition will earn my undying gratitude. > > Thanks. > > Christian, if you send me a more complete dmesg output, along with your .config and an lspci, I will look at them. I have been using 2.6 on a ton of stuff. If you have a problem, it could be ACPI related. (if so, try: pci=noacpi on boot) Kill your initrd (if you can) - I have had TONS of problems with 2.6.[1-3] and mkinitrd - it does not generate complete initrd's all the time. If you have serial console configured, then modify your boot command line as such: kernel /vmlinuz-2.6.3 root=303 mem=nopentium idebus=66 console=tty0 console=ttyS0,3008n1 it doesn't matter whether or not ttyS0 is plugged in, the entire boot will run as though it is being pushed out a 300 baud serial device, hence the entire thing will be readable. See if you are seeing the ide drives getting probed, and if you are seeing the correct partitions. thanks, joshua From owner-linux-xfs@oss.sgi.com Fri Mar 5 09:33:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Mar 2004 09:33:43 -0800 (PST) Received: from mail.pacrimopen.com ([64.65.177.98]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i25HXeKO001806 for ; Fri, 5 Mar 2004 09:33:40 -0800 Received: from mail.pacrimopen.com (localhost [127.0.0.1]) by mail.pacrimopen.com (Postfix) with ESMTP id 0650F70007A6 for ; Fri, 5 Mar 2004 09:35:56 -0800 (PST) Received: from UNKNOWN(127.0.0.1), claiming to be "mail.pacrimopen.com" via SMTP by sa-relay.pacrimopen.com, id smtpdSVkWkc; Fri Mar 5 09:35:53 2004 Received: from bubbles.imr-net.com (unknown [12.111.175.170]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pacrimopen.com (Postfix) with ESMTP id DE67A70007A6 for ; Fri, 5 Mar 2004 09:35:47 -0800 (PST) Subject: Re: realtime subvolumes, again! From: Joshua Schmidlkofer To: XFS List In-Reply-To: References: Content-Type: text/plain Message-Id: <1078507663.9724.14.camel@bubbles.imr-net.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 05 Mar 2004 09:27:44 -0800 Content-Transfer-Encoding: 7bit X-archive-position: 2361 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: menion@asylumwear.com Precedence: bulk X-list: linux-xfs Content-Length: 2272 Lines: 56 On Fri, 2004-03-05 at 03:59, Ramesh K wrote: > Hello, > I finally managed to get realtime subvolumes working in my system. I > built a new kernel using the sources at SGI (Kernel 2.4.25). I have also been > testing the realtime subvolumes with my application. > The application writes data to a XFS realtime subvolume at 80 > MBytes/sec. I'm using 3ware Raid Controller 7810, configured as RAID 0 with 64K > stripes. > The man page of mk.xfs says, "the real-time extent size should be > carefully chosen to match the parameters of the physical media used" - can > someone say more about this? What more do I need to know about the ophysical > media? > Here's the output generated by xfs_info: > > /******************************************************/ > kram@dop93:~> xfs_info /data > meta-data=/data isize=256 agcount=25, agsize=1048576 blks > = sectsz=512 > data = bsize=4096 blocks=25601577, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=12500, version=1 > = sectsz=512 sunit=0 blks > realtime =external extsz=65536 blocks=208836967, > rtextents=13052310 > > /****************************************************/ > > The RAID controller document says that smaller stripe width is more > suited for sequential access, and that is what I do. I use preallocated files > in realtime subvolume. What I see is the disk-pack exhibits some sort of > sponginess with time. Is it entirely due to the RAID Controller + harddisk > combination, or is it something from XFS realtime subvolumes? I can include some > statistics of the latencies if you need. > Thank you. > > Regards > Ramesh > > I think with RAID-0 you will want to recreate the filesystem using sunit and swidth, on both the log on the data. There are better minds than mine for this on here, but I think that "-d swidth=(n disks),sunit=64k" Someone may comment on log size - I don't know if it should be largers, I think for the log you want "-l sunit=128" [isn't the sunit here in 512 blocks?] . thanks, joshua From owner-linux-xfs@oss.sgi.com Fri Mar 5 12:21:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Mar 2004 12:21:08 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i25KL6KO009249 for ; Fri, 5 Mar 2004 12:21:07 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i25KL1o4012821 for ; Fri, 5 Mar 2004 14:21:01 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i25KL0Ke34984810 for ; Fri, 5 Mar 2004 14:21:01 -0600 (CST) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i25KKxXa587349; Fri, 5 Mar 2004 14:20:59 -0600 (CST) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id i25KK8KW005318; Fri, 5 Mar 2004 14:20:08 -0600 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id i25KK7Xr005316; Fri, 5 Mar 2004 14:20:07 -0600 Date: Fri, 5 Mar 2004 14:20:07 -0600 From: Eric Sandeen Message-Id: <200403052020.i25KK7Xr005316@penguin.americas.sgi.com> Subject: TAKE 910387 - zero log buffer during initialization at mount time X-archive-position: 2362 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 321 Lines: 13 Date: Fri Mar 5 12:20:09 PST 2004 Workarea: penguin.americas.sgi.com:/src/eric/linux-2.4.x Inspected by: overby The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:167980a fs/xfs/xfs_log.c - 1.290 - zero log buffer during initialization at mount time From owner-linux-xfs@oss.sgi.com Fri Mar 5 16:14:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Mar 2004 16:14:39 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i260EYKO021236 for ; Fri, 5 Mar 2004 16:14:35 -0800 Received: from extimap.suse.de (extimap.suse.de [195.135.220.6]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id C724229FD7B for ; Sat, 6 Mar 2004 01:14:28 +0100 (CET) Received: by extimap.suse.de (Postfix, from userid 65534) id 92DA47CF9F; Sat, 6 Mar 2004 01:14:23 +0100 (CET) Received: from watt.suse.com (roc-24-169-15-66.rochester.rr.com [24.169.15.66]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by extimap.suse.de (Postfix) with ESMTP id EEAB57CCBB; Sat, 6 Mar 2004 01:13:39 +0100 (CET) Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 From: Chris Mason To: Johannes Stezenbach Cc: Peter Nelson , Hans Reiser , Jens Axboe , linux-kernel@vger.kernel.org, ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com In-Reply-To: <20040303234104.GD1875@convergence.de> References: <4044119D.6050502@andrew.cmu.edu> <4044366B.3000405@namesys.com> <4044B787.7080301@andrew.cmu.edu> <20040303234104.GD1875@convergence.de> Content-Type: text/plain Message-Id: <1078532181.25062.144.camel@watt.suse.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 05 Mar 2004 19:16:22 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2363 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mason@suse.com Precedence: bulk X-list: linux-xfs Content-Length: 1972 Lines: 46 On Wed, 2004-03-03 at 18:41, Johannes Stezenbach wrote: > Peter Nelson wrote: > > Hans Reiser wrote: > > > > >Are you sure your benchmark is large enough to not fit into memory, > > >particularly the first stages of it? It looks like not. reiser4 is > > >much faster on tasks like untarring enough files to not fit into ram, > > >but (despite your words) your results seem to show us as slower unless > > >I misread them.... > > > > I'm pretty sure most of the benchmarking I am doing fits into ram, > > particularly because my system has 1GB of it, but I see this as > > realistic. When I download a bunch of debs (or rpms or the kernel) I'm > > probably going to install them directly with them still in the file > > cache. Same with rebuilding the kernel after working on it. > > OK, that test is not very interesting for the FS gurus because it > doesn't stress the disk enough. > > Anyway, I have some related questions concerning disk/fs performance: > > o I see you are using and IDE disk with a large (8MB) write cache. > > My understanding is that enabling write cache is a risky > thing for journaled file systems, so for a fair comparison you > would have to enable the write cache for ext2 and disable it > for all journaled file systems. > > It would be nice if someone with more profound knowledge could comment > on this, but my understanding of the problem is: > Jens just sent me an updated version of his IDE barrier code, and I'm adding support for reiserfs and ext3 to it this weekend. It's fairly trivial to add support for each FS, I just don't know the critical sections of the others as well. The SUSE 2.4 kernels have had various forms of the patch, it took us a while to get things right. It does impact performance slightly, since we are forcing cache flushes that otherwise would not have been done. The common workloads don't slow down with the patch, fsync heavy workloads typically lose around 10%. -chris From owner-linux-xfs@oss.sgi.com Fri Mar 5 16:42:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Mar 2004 16:42:23 -0800 (PST) Received: from mail.rd.arkonnetworks.com (mail.rd.arkonnetworks.com [207.34.136.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i260gKKO025626 for ; Fri, 5 Mar 2004 16:42:20 -0800 Received: from rd.arkonnetworks.com (unknown [207.34.136.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Norman_Zhang", Issuer "mail.rd.arkonnetworks.com" (verified OK)) by mail.rd.arkonnetworks.com (Postfix) with ESMTP id 7E1E41803B72 for ; Fri, 5 Mar 2004 16:42:15 -0800 (PST) Message-ID: <40491E66.8030802@rd.arkonnetworks.com> Date: Fri, 05 Mar 2004 16:42:14 -0800 From: Norman Zhang User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Quota Backup Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2364 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: norman.zhang@rd.arkonnetworks.com Precedence: bulk X-list: linux-xfs Content-Length: 1008 Lines: 31 Hi, I'm trying to use xfsdq/xfsrq to backup/restore the Quota of XFS partitions from one machine to another. However, the disk on the other machine is on a different host/bus/. Also the Samba users are of differnent uid. Can xfsdq/xfsrq do the job? Please help. I tried, # xfsdq -u xfshome /home # on machine1 # xfsrq -u xfshome # on machine2 but got the following error messages, Bugs to: mvw@planets.elm.net, jack@suse.cz setting quota for id=10091 dev=/dev/scsi/host1/bus0/target0/lun0/part7 setquota: invalid option -- n setquota: Usage: setquota [-u|-g] [-F quotaformat] -a|... setquota [-u|-g] [-F quotaformat] <-p protouser|protogroup> -a|... setquota [-u|-g] [-F quotaformat] -t -a|... setquota [-u|-g] [-F quotaformat] -T -a|... Regards, Norman From owner-linux-xfs@oss.sgi.com Fri Mar 5 16:50:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Mar 2004 16:50:29 -0800 (PST) Received: from internalmx.vasoftware.com (internalmx.vasoftware.com [198.186.202.175]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i260oQKO026062 for ; Fri, 5 Mar 2004 16:50:26 -0800 Received: from adsl-67-123-173-11.dsl.sntc01.pacbell.net ([67.123.173.11]:64256 helo=linux-sxs.org) by internalmx.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.22 #1 (Debian)) id 1AzQ1F-0007cU-J4 by VAauthid with fixed_plain for ; Fri, 05 Mar 2004 16:50:21 -0800 Message-ID: <40492044.9040905@linux-sxs.org> Date: Fri, 05 Mar 2004 16:50:12 -0800 From: "Net Llama!" Organization: HAL III User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040119 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: fedora core2-test1 & XFS Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-EA-Verified: internalmx.vasoftware.com 1AzQ1F-0007cU-J4 49043c751a5b4dd1d4cb3ed9b0896f4c X-archive-position: 2365 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 348 Lines: 9 Does anyone know if Fedora core2-test1 has XFS support in the installer? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 16:45:01 up 89 days, 21:24, 1 user, load average: 0.04, 0.10, 0.14 From owner-linux-xfs@oss.sgi.com Fri Mar 5 20:42:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Mar 2004 20:42:44 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i264gfKO032626 for ; Fri, 5 Mar 2004 20:42:41 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i264TZ02030822 for ; Fri, 5 Mar 2004 20:29:35 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i264TYKe35078622; Fri, 5 Mar 2004 22:29:35 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i264TYEr1357086; Fri, 5 Mar 2004 22:29:34 -0600 (CST) Date: Fri, 5 Mar 2004 22:29:34 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Net Llama! cc: linux-xfs@oss.sgi.com Subject: Re: fedora core2-test1 & XFS In-Reply-To: <40492044.9040905@linux-sxs.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2366 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 560 Lines: 20 I believe it does, as an unsupported option - try booting "linux xfs" at the prompt, or something like that. And let us know how it goes. :) -eric On Fri, 5 Mar 2004, Net Llama! wrote: > Does anyone know if Fedora core2-test1 has XFS support in the installer? > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > L. Friedman netllama@linux-sxs.org > Linux Step-by-step & TyGeMo: http://netllama.ipfox.com > > 16:45:01 up 89 days, 21:24, 1 user, load average: 0.04, 0.10, 0.14 > > From owner-linux-xfs@oss.sgi.com Fri Mar 5 21:03:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Mar 2004 21:03:55 -0800 (PST) Received: from priv-edtnes57.telusplanet.net (outbound01.telus.net [199.185.220.220]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2653rKO000706 for ; Fri, 5 Mar 2004 21:03:53 -0800 Received: from telus.net ([209.89.199.125]) by priv-edtnes57.telusplanet.net (InterMail vM.6.00.05.02 201-2115-109-103-20031105) with ESMTP id <20040306050347.ELYU7704.priv-edtnes57.telusplanet.net@telus.net>; Fri, 5 Mar 2004 22:03:47 -0700 Message-ID: <40495BB8.3030708@telus.net> Date: Fri, 05 Mar 2004 22:03:52 -0700 From: Aly Dharshi User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: "Net Llama!" , linux-xfs@oss.sgi.com Subject: Re: fedora core2-test1 & XFS References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2367 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: aly.dharshi@telus.net Precedence: bulk X-list: linux-xfs Content-Length: 498 Lines: 27 Eric, This is rather good news, I look forward to using XFS in Fedora Core 2 ! Cheers and keep up the great work ! Aly. Eric Sandeen wrote: > I believe it does, as an unsupported option - try > booting "linux xfs" at the prompt, or something like that. > > And let us know how it goes. :) > > -eric -- Aly Dharshi aly.dharshi@telus.net "A good speech is like a good dress that's short enough to be interesting and long enough to cover the subject" From owner-linux-xfs@oss.sgi.com Fri Mar 5 23:53:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Mar 2004 23:53:18 -0800 (PST) Received: from malik.acsalaska.net (malik.acsalaska.net [209.112.155.41]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i267rEKO003287 for ; Fri, 5 Mar 2004 23:53:14 -0800 Received: from erbenson.alaska.net (2-pm21.nwc.acsalaska.net [209.112.143.2]) by malik.acsalaska.net (8.12.10/8.12.10) with ESMTP id i267rClT051635 for ; Fri, 5 Mar 2004 22:53:12 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 17E7739E6 for ; Fri, 5 Mar 2004 22:53:11 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 54BD240FF35; Fri, 5 Mar 2004 22:53:11 -0900 (AKST) Date: Fri, 5 Mar 2004 22:53:11 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Quota Backup Message-ID: <20040306075311.GJ1003@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <40491E66.8030802@rd.arkonnetworks.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bWEb1MG/o7IKOlQF" Content-Disposition: inline In-Reply-To: <40491E66.8030802@rd.arkonnetworks.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.63; spamdefang 1.93 X-archive-position: 2368 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 2302 Lines: 72 --bWEb1MG/o7IKOlQF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 05, 2004 at 04:42:14PM -0800, Norman Zhang wrote: > Hi, >=20 > I'm trying to use xfsdq/xfsrq to backup/restore the Quota of XFS=20 > partitions from one machine to another. However, the disk on the other=20 > machine is on a different host/bus/. Also the Samba users are of=20 > differnent uid. Can xfsdq/xfsrq do the job? Please help. >=20 > I tried, >=20 > # xfsdq -u xfshome /home # on machine1 > # xfsrq -u xfshome # on machine2 >=20 > but got the following error messages, >=20 > Bugs to: mvw@planets.elm.net, jack@suse.cz > setting quota for id=3D10091 dev=3D/dev/scsi/host1/bus0/target0/lun0/part7 > setquota: invalid option -- n > setquota: Usage: > setquota [-u|-g] [-F quotaformat] > =20 > -a|... > setquota [-u|-g] [-F quotaformat] <-p protouser|protogroup>=20 > -a|... > setquota [-u|-g] [-F quotaformat] -t =20 > -a|... > setquota [-u|-g] [-F quotaformat] -T =20 > -a|... try with this patch: --- /usr/sbin/xfsrq Sun Jul 13 19:48:59 2003 +++ xfsrq Sun Aug 10 15:00:31 2003 @@ -66,7 +66,7 @@ # blk conversion (512 -> 1024) bsoft=3D`expr $bsoft / 2` bhard=3D`expr $bhard / 2` - setquota $OPTS -n $id $fs $bsoft $bhard $isoft $iha= rd + setquota $OPTS $id $bsoft $bhard $isoft $ihard $fs done ;; *) echo $USAGE 1>&2 i have been meaning to check current quota utils to see if its just the older version i have which lacks the -n switch , or if the xfsrq script is just broken. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --bWEb1MG/o7IKOlQF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkBJg2cACgkQJKx7GixEevxyowCgmMTGcchKNsIKsd7/twjq46O7 ii4AoJWCnPeI7Fkl+9W6e1HaY3s97beF =2Gg9 -----END PGP SIGNATURE----- --bWEb1MG/o7IKOlQF-- From owner-linux-xfs@oss.sgi.com Sat Mar 6 02:55:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 06 Mar 2004 02:55:51 -0800 (PST) Received: from smtp3.cwidc.net (smtp3.cwidc.net [154.33.63.113]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i26AtiKO011313 for ; Sat, 6 Mar 2004 02:55:45 -0800 Received: from [211.14.136.222] (helo=tequila.co.jp) by smtp3.cwidc.net with esmtp (Exim 3.36 #2) id 1Az4cv-00054S-00; Fri, 05 Mar 2004 10:59:49 +0900 Message-ID: <4047DF05.8080209@tequila.co.jp> Date: Fri, 05 Mar 2004 10:59:33 +0900 From: Clemens Schwaighofer Organization: Tequila \ Japan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040210 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Felipe Alfaro Solana CC: Robin Rosenberg , David Weinehall , Andrew Ho , Dax Kelson , Peter Nelson , Hans Reiser , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 References: <4044119D.6050502@andrew.cmu.edu> <200403030700.57164.robin.rosenberg.lists@dewire.com> <1078307033.904.1.camel@teapot.felipe-alfaro.com> <200403031059.26483.robin.rosenberg.lists@dewire.com> <1078309141.863.3.camel@teapot.felipe-alfaro.com> In-Reply-To: <1078309141.863.3.camel@teapot.felipe-alfaro.com> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2369 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cs@tequila.co.jp Precedence: bulk X-list: linux-xfs Content-Length: 1762 Lines: 44 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Felipe Alfaro Solana wrote: | The problem is that I couldn't save anything: the XFS volume refused to | mount and the XFS recovery tools refused to fix anything. It was just a | single disk bad block. For example in ext2/3 critical parts are | replicated several times over the volume, so there's minimal chance of | being unable to mount the volume and recover important files. just my two cents here: if you have an XFS volume, then you mostly do more than just storing your baby photos, so you should have a raid below (software or hardware) and then you don't worry about bad blocks, because a) you have a raid (probably with a hot spare drive) and b) a daly (or more often) backup. as for me I stopped using raiser, jfs or xfs at home. why? too many negative experience. bad blocks (xfs total b0rked), raiserfs (similar things) and I even didn't try jfs. with ext3 it works very well. yes I do have a crappy board with a sucky via chipset and some super super old hds, but with ext3 I had NO single problem since 6 months (heavily knocking on wood here). all those high end journaling file systems are no good for home systems in my opinion but again, those are just my little two cents here - -- Clemens Schwaighofer - IT Engineer & System Administration ========================================================== Tequila Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343 http://www.tequila.jp ========================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAR98FjBz/yQjBxz8RAjbtAJ9gyiy3QNak2NgsFyWGm355wshhMgCgz/5E r9ARfA4kajBAUZCLOFBi0gw= =InvR -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sat Mar 6 03:42:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 06 Mar 2004 03:42:55 -0800 (PST) Received: from hotmail.com (bay4-f26.bay4.hotmail.com [65.54.171.26]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i26BgqKO013302 for ; Sat, 6 Mar 2004 03:42:52 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 6 Mar 2004 03:42:47 -0800 Received: from 62.114.196.113 by by4fd.bay4.hotmail.msn.com with HTTP; Sat, 06 Mar 2004 11:42:46 GMT X-Originating-IP: [62.114.196.113] X-Originating-Email: [sigsegv@msn.com] X-Sender: sigsegv@msn.com From: "Stack Overflow" To: linux-xfs@oss.sgi.com Subject: Too many dirs Date: Sat, 06 Mar 2004 13:42:46 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Mar 2004 11:42:47.0251 (UTC) FILETIME=[256FA230:01C40370] X-archive-position: 2370 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sigsegv@msn.com Precedence: bulk X-list: linux-xfs Content-Length: 1388 Lines: 30 Hi, I have about 1,000,000 directories currently stored on an ext3 partition. I want to move data to xfs. Due to ext3 limitations I apply a directory hashing algorithm to place those 1M directories into other subdirectories so that the maximum number of inodes in a directory does not exceed 32K ( ext3 limit ). I know that xfs does not have this limitation , and I read that it uses balanced trees to organize directories, but is it better in xfs to have all those 1M directories in a single flat level ( I never need to ls or readdir them all ) , or stick to balance them in three or four levels ? I also wonder if xfs performance is good for too many small files or not. I know it is the best for large files, but this is not my case ( my avarage file size is about 140k ) . If xfs is not the best choice for me , can you please suggest me a more suitable alternative. One last question, I see that development in xfs is very active , Changelog is big :) does that mean that people who want to update their xfs to the latest code will need to backup and reformat partition with the new version , or just upgrade the kernel patches and program on the same filesystem ? Best regards sigsegv _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From owner-linux-xfs@oss.sgi.com Sat Mar 6 04:42:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 06 Mar 2004 04:42:56 -0800 (PST) Received: from atrey.karlin.mff.cuni.cz (postfix@atrey.karlin.mff.cuni.cz [195.113.31.123]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i26CgqKO019363 for ; Sat, 6 Mar 2004 04:42:53 -0800 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id 55EB54C03D9; Sat, 6 Mar 2004 13:42:43 +0100 (CET) Date: Fri, 5 Mar 2004 19:46:46 +0100 From: Pavel Machek To: Johannes Stezenbach , Peter Nelson , Hans Reiser , Jens Axboe , linux-kernel@vger.kernel.org, ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 Message-ID: <20040305184643.GA4758@openzaurus.ucw.cz> References: <4044119D.6050502@andrew.cmu.edu> <4044366B.3000405@namesys.com> <4044B787.7080301@andrew.cmu.edu> <20040303234104.GD1875@convergence.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040303234104.GD1875@convergence.de> User-Agent: Mutt/1.3.27i X-archive-position: 2371 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pavel@suse.cz Precedence: bulk X-list: linux-xfs Content-Length: 1378 Lines: 30 Hi! > It would be nice if someone with more profound knowledge could comment > on this, but my understanding of the problem is: > > - journaled filesystems can only work when they can enforce that > journal data is written to the platters at specifc times wrt > normal data writes > - IDE write caching makes the disk "lie" to the kernel, i.e. it says > "I've written the data" when it was only put in the cache > - now if a *power failure* keeps the disk from writing the cache > contents to the platter, the fs and journal are inconsistent > (a kernel crash would not cause this problem because the disk can > still write the cache contents to the platters) > - at next mount time the fs will read the journal from the disk > and try to use it to bring the fs into a consistent state; > however, since the journal on disk is not guaranteed to be up to date > this can *fail* (I have no idea what various fs implementations do > to handle this; I suspect they at least refuse to mount and require > you to manually run fsck. Or they don't notice and let you work > with a corrupt filesystem until they blow up.) > > Right? Or is this just paranoia? Twice a year I fsck my reiser drives, and yes there's some corruption there. So you are right, and its not paranoia. -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms From owner-linux-xfs@oss.sgi.com Sat Mar 6 07:18:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 06 Mar 2004 07:18:08 -0800 (PST) Received: from lists.vasoftware.com (mail@lists.vasoftware.com [198.186.202.171]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i26FI6KO026342 for ; Sat, 6 Mar 2004 07:18:06 -0800 Received: from adsl-67-123-173-11.dsl.sntc01.pacbell.net ([67.123.173.11]:61997 helo=linux-sxs.org) by lists.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.20 #1 (Debian)) id 1AzdYX-0007OD-DE by VAauthid with fixed_plain; Sat, 06 Mar 2004 07:17:37 -0800 Message-ID: <4049EB84.8050907@linux-sxs.org> Date: Sat, 06 Mar 2004 07:17:24 -0800 From: "Net Llama!" Organization: HAL III User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040119 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stack Overflow CC: linux-xfs@oss.sgi.com Subject: Re: Too many dirs References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-EA-Verified: lists.vasoftware.com 1AzdYX-0007OD-DE 9ba36747eb818eb1ec5328fada10eb2a X-archive-position: 2372 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 846 Lines: 19 On 03/06/04 03:42, Stack Overflow wrote: > One last question, I see that development in xfs is very active , > Changelog is big :) does that mean that people who want to update their > xfs to the latest code will need to backup and reformat partition with > the new version , or just upgrade the kernel patches and program on the > same filesystem ? I can't answer your other questions, but this last is easy. You just need to upgrade your kernel. I doubt anyone would have any serious interest in XFS if they had to reformat their partition with each release. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 07:15:01 up 90 days, 11:54, 1 user, load average: 0.15, 0.17, 0.11 From owner-linux-xfs@oss.sgi.com Sat Mar 6 10:44:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 06 Mar 2004 10:44:23 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i26IiLKO005298 for ; Sat, 6 Mar 2004 10:44:21 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i26IiFXM017162 for ; Sat, 6 Mar 2004 12:44:15 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i26IiFKe35113016; Sat, 6 Mar 2004 12:44:15 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i26IiFEr1412851; Sat, 6 Mar 2004 12:44:15 -0600 (CST) Date: Sat, 6 Mar 2004 12:44:15 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Net Llama! cc: Stack Overflow , Subject: Re: Too many dirs In-Reply-To: <4049EB84.8050907@linux-sxs.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2373 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 846 Lines: 19 On Sat, 6 Mar 2004, Net Llama! wrote: > On 03/06/04 03:42, Stack Overflow wrote: > > One last question, I see that development in xfs is very active , > > Changelog is big :) does that mean that people who want to update their > > xfs to the latest code will need to backup and reformat partition with > > the new version , or just upgrade the kernel patches and program on the > > same filesystem ? > > I can't answer your other questions, but this last is easy. You just > need to upgrade your kernel. I doubt anyone would have any serious > interest in XFS if they had to reformat their partition with each release. Right - on-disk format rarely changes, and always in a backwards-compatible fashion when it does. (Remember, there have been Irix users of XFS for many years - they would not tolerate incompatible changes.) -Eric From owner-linux-xfs@oss.sgi.com Sun Mar 7 01:37:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 07 Mar 2004 01:38:19 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i279btKO000300 for ; Sun, 7 Mar 2004 01:37:55 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AzujB-0003pJ-9X; Sun, 07 Mar 2004 09:37:45 +0000 Date: Sun, 7 Mar 2004 09:37:45 +0000 From: Christoph Hellwig To: Dave Kleikamp Cc: Andrew Morton , linux-kernel , linux-xfs@oss.sgi.com, Dave Blaschke Subject: Re: [PATCH] JFS DMAPI Message-ID: <20040307093745.A14680@infradead.org> Mail-Followup-To: Christoph Hellwig , Dave Kleikamp , Andrew Morton , linux-kernel , linux-xfs@oss.sgi.com, Dave Blaschke References: <1078444492.9162.56.camel@shaggy.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1078444492.9162.56.camel@shaggy.austin.ibm.com>; from shaggy@austin.ibm.com on Thu, Mar 04, 2004 at 05:54:52PM -0600 X-archive-position: 2374 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 1931 Lines: 38 On Thu, Mar 04, 2004 at 05:54:52PM -0600, Dave Kleikamp wrote: > Andrew, > Would you consider adding this patch to -mm? This would add the DMAPI > interface to JFS. This function has long been requested by HSMs > (Hierarchical Storage Managers). It is based on SGI's XFS > implementation, but has been clean up to avoid their vnode interface. Umm, no. There's a reason the XFS code this is based on isn't merged, and the problem is the DMAPI spec. E.g. you still have this utterly incompatible to Linux semantics of providing a mount option to specifiy the canonical name for a mount point as dmapi doesn't understand the concept of multiple mounts for a given fs or namespaces, you still don't get the post-unmount even rights, the handle2path stuff is still as broken, how do you handle the mprotect vs dmapi regions interaction the 2.4 XFS tree has the mprotect vm operation hack for, etc..? So the question is whether IBM just wants to provide this for customers that can live with the incompatbilities or really wants to provide HSM support for mainline. In the first case I'd suggest you clean up the changes to the JFS core to not require ifdefs all over the place and submit that one for mainline inclusion so the dmapi dir can more less be dropped into the tree ala XFS. If IBM actually wants to support proper HSM support for Linux let's go back to the drawing board. Some specific requirements: - move the events from fs-specific code to common code. That we have two filesystems now that want it shows pretty much that fs-specific code is the wrong place. - get rid of the concept of a canoical path in kernelspace. If userspace wants it they can't search the mount tab for the right st_dev to provide dmapi semantics. - clean up the whole ioctl API mess. I think we'd mostly be done with a O_HSM option for open to avoid interactions with the callouts and some generic handle API. From owner-linux-xfs@oss.sgi.com Sun Mar 7 12:16:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 07 Mar 2004 12:16:15 -0800 (PST) Received: from mail.ocs.com.au (pr-117-210.ains.net.au [202.147.117.210] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i27KG9KO023180 for ; Sun, 7 Mar 2004 12:16:12 -0800 Received: from ocs3.ocs.com.au (ocs3.ocs.com.au [192.168.255.3]) by mail.ocs.com.au (Postfix) with ESMTP id 469101800A6; Mon, 8 Mar 2004 07:16:06 +1100 (EST) Received: by ocs3.ocs.com.au (Postfix, from userid 16331) id D91ABC00AD; Mon, 8 Mar 2004 07:15:49 +1100 (EST) Received: from ocs3.ocs.com.au (localhost [127.0.0.1]) by ocs3.ocs.com.au (Postfix) with ESMTP id D6688140086; Mon, 8 Mar 2004 07:15:49 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Kelledin Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS and ACLs in 2.4.25...what happen? In-reply-to: Your message of "Sun, 07 Mar 2004 11:26:45 MDT." <200403071126.45942.kelledin+XFS@skarpsey.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Mar 2004 07:15:48 +1100 Message-ID: <27232.1078690548@ocs3.ocs.com.au> X-archive-position: 2375 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@ocs.com.au Precedence: bulk X-list: linux-xfs Content-Length: 256 Lines: 8 On Sun, 7 Mar 2004 11:26:45 -0600, Kelledin wrote: >So what gives? What happened to XFS ACL support? ftp://oss.sgi.com/projects/xfs/download/patches/2.4.24-pre1/xfs-2.4.24-pre1-split-acl.bz2 should be want you want. From owner-linux-xfs@oss.sgi.com Sun Mar 7 15:20:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 07 Mar 2004 15:20:11 -0800 (PST) Received: from mx.ktv.lt ([213.226.134.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i27NK2KO004610 for ; Sun, 7 Mar 2004 15:20:05 -0800 Received: by mx.ktv.lt (Postfix, from userid 426) id 63FEA63C3; Mon, 8 Mar 2004 01:20:39 +0200 (EET) Received: from nerijus.sat.lt (g0u16.vrs.dtiltas.lt [213.252.208.16]) by mx.ktv.lt (Postfix) with ESMTP id 5504A62C8 for ; Mon, 8 Mar 2004 01:20:39 +0200 (EET) Received: (qmail 22852 invoked from network); 7 Mar 2004 23:12:33 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 7 Mar 2004 23:12:33 -0000 Date: Mon, 8 Mar 2004 01:12:33 +0200 (EET) From: Nerijus Baliunas Subject: Re: XFS and ACLs in 2.4.25...what happen? To: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE References: <27232.1078690548@ocs3.ocs.com.au> In-Reply-To: <27232.1078690548@ocs3.ocs.com.au> X-Mailer: Mahogany 0.65.0 'Claire', compiled for Linux 2.4.18-rc4 i686 Message-Id: <20040307232039.5504A62C8@mx.ktv.lt> X-archive-position: 2376 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nerijus@users.sourceforge.net Precedence: bulk X-list: linux-xfs Content-Length: 327 Lines: 14 On Mon, 08 Mar 2004 07:15:48 +1100 Keith Owens wrote: > >So what gives? What happened to XFS ACL support? > > ftp://oss.sgi.com/projects/xfs/download/patches/2.4.24-pre1/xfs-2.4.24-pre1-split-acl.bz2 > > should be want you want. Why isn't it included in 2.4.25? Is it included in 2.6? Regards, Nerijus From owner-linux-xfs@oss.sgi.com Sun Mar 7 17:54:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 07 Mar 2004 17:54:47 -0800 (PST) Received: from hermes.acsalaska.net (hermes.acsalaska.net [209.112.155.38]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i281scKO014540 for ; Sun, 7 Mar 2004 17:54:39 -0800 Received: from erbenson.alaska.net (155-pm15.nwc.acsalaska.net [209.112.141.155]) by hermes.acsalaska.net (8.12.11/8.12.11) with ESMTP id i280DfrA093662; Sun, 7 Mar 2004 15:13:41 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 41F803A5C; Sun, 7 Mar 2004 15:13:38 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id BEF4C40FF35; Sun, 7 Mar 2004 15:13:37 -0900 (AKST) Date: Sun, 7 Mar 2004 15:13:37 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: XFS and ACLs in 2.4.25...what happen? Message-ID: <20040308001337.GA2022@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org References: <27232.1078690548@ocs3.ocs.com.au> <20040307232039.5504A62C8@mx.ktv.lt> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline In-Reply-To: <20040307232039.5504A62C8@mx.ktv.lt> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: erbenson@alaska.net X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.39; SA 2.63; spamdefang 1.93 X-archive-position: 2377 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 4412 Lines: 140 --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 08, 2004 at 01:12:33AM +0200, Nerijus Baliunas wrote: > On Mon, 08 Mar 2004 07:15:48 +1100 Keith Owens wrote: >=20 > > >So what gives? What happened to XFS ACL support? > >=20 > > ftp://oss.sgi.com/projects/xfs/download/patches/2.4.24-pre1/xfs-2.4.24-= pre1-split-acl.bz2 > >=20 > > should be want you want. >=20 > Why isn't it included in 2.4.25? because Marcelo said no. > Is it included in 2.6? yes. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkBLurEACgkQJKx7GixEevzj9QCfdgpY1g+UN0uqa4UdePfuJzy/ NBUAoIKz4ume1UqUxe4ebrWvklMVbIWJ =Oeut -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz-- rom owner-linux-xfs@oss.sgi.com Sun Mar 7 19:32:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 07 Mar 2004 19:32:32 -0800 (PST) Received: from omr-m01.mx.aol.com (omr-m01.mx.aol.com [64.12.138.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i283WEKO020865 for ; Sun, 7 Mar 2004 19:32:14 -0800 Received: from rly-xk03.mx.aol.com (rly-xk03.mail.aol.com [172.20.83.40]) by omr-m01.mx.aol.com (v97.10) with ESMTP id RELAYIN3-4404be91c13; Sun, 07 Mar 2004 22:31:40 -0500 Received: from localhost (localhost) by rly-xk03.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with internal id WAC19199; Sun, 7 Mar 2004 22:31:40 -0500 (EST) Date: Sun, 7 Mar 2004 22:31:40 -0500 (EST) From: Mail Delivery Subsystem Message-Id: <200403080331.WAC19199@rly-xk03.mx.aol.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="WAC19199.1078716700/rly-xk03.mx.aol.com" Subject: Returned mail: User unknown Auto-Submitted: auto-generated (failure) X-AOL-IP: 172.20.83.40 X-archive-position: 2378 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@aol.com Precedence: bulk X-list: linux-xfs This is a MIME-encapsulated message --WAC19199.1078716700/rly-xk03.mx.aol.com The original message was received at Sun, 7 Mar 2004 22:31:23 -0500 (EST) from [203.93.63.248] *** ATTENTION *** Your e-mail is being returned to you because there was a problem with its delivery. The address which was undeliverable is listed in the section labeled: "----- The following addresses had permanent fatal errors -----". The reason your mail is being returned to you is listed in the section labeled: "----- Transcript of Session Follows -----". The line beginning with "<<<" describes the specific reason your e-mail could not be delivered. The next line contains a second error message which is a general translation for other e-mail servers. Please direct further questions regarding this message to your e-mail administrator. --AOL Postmaster ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to air-xk02.mail.aol.com.: >>> RCPT To: <<< 550 MAILBOX NOT FOUND 550 ... User unknown --WAC19199.1078716700/rly-xk03.mx.aol.com Content-Type: message/delivery-status Reporting-MTA: dns; rly-xk03.mx.aol.com Arrival-Date: Sun, 7 Mar 2004 22:31:23 -0500 (EST) Final-Recipient: RFC822; macmaninfi@aol.com Action: failed Status: 5.1.1 Remote-MTA: DNS; air-xk02.mail.aol.com Diagnostic-Code: SMTP; 550 MAILBOX NOT FOUND Last-Attempt-Date: Sun, 7 Mar 2004 22:31:40 -0500 (EST) --WAC19199.1078716700/rly-xk03.mx.aol.com Content-Type: text/rfc822-headers Received: from aol.com ([203.93.63.248]) by rly-xk03.mx.aol.com (v98.5) with ESMTP id MAILRELAYINXK36-588404be90834c; Sun, 07 Mar 2004 22:31:22 -0500 From: linux-xfs@oss.sgi.com To: macmaninfi@aol.com Subject: Re: Word file Date: Mon, 8 Mar 2004 12:11:07 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_00003D10.00000084" X-Priority: 3 X-MSMail-Priority: Normal X-AOL-IP: 203.93.63.248 X-AOL-SCOLL-SCORE: 0:XXX:XX X-AOL-SCOLL-URL_COUNT: 0 Message-ID: <200403072231.588404be90834c@rly-xk03.mx.aol.com> --WAC19199.1078716700/rly-xk03.mx.aol.com-- From owner-linux-xfs@oss.sgi.com Mon Mar 8 10:20:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Mar 2004 10:20:26 -0800 (PST) Received: from mail.rd.arkonnetworks.com (mail.rd.arkonnetworks.com [207.34.136.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i28IKLKO027915 for ; Mon, 8 Mar 2004 10:20:21 -0800 Received: from rd.arkonnetworks.com (unknown [207.34.136.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Norman_Zhang", Issuer "mail.rd.arkonnetworks.com" (verified OK)) by mail.rd.arkonnetworks.com (Postfix) with ESMTP id 38E6D1801BA2; Mon, 8 Mar 2004 10:20:15 -0800 (PST) Message-ID: <404CB95B.8050105@rd.arkonnetworks.com> Date: Mon, 08 Mar 2004 10:20:11 -0800 From: Norman Zhang User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ethan Benson Cc: linux-xfs@oss.sgi.com Subject: Re: Quota Backup References: <40491E66.8030802@rd.arkonnetworks.com> <20040306075311.GJ1003@plato.local.lan> In-Reply-To: <20040306075311.GJ1003@plato.local.lan> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2379 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: norman.zhang@rd.arkonnetworks.com Precedence: bulk X-list: linux-xfs Content-Length: 2490 Lines: 69 Ethan Benson wrote: > On Fri, Mar 05, 2004 at 04:42:14PM -0800, Norman Zhang wrote: >> >>I'm trying to use xfsdq/xfsrq to backup/restore the Quota of XFS >>partitions from one machine to another. However, the disk on the other >>machine is on a different host/bus/. Also the Samba users are of >>differnent uid. Can xfsdq/xfsrq do the job? Please help. >> >>I tried, >> >># xfsdq -u xfshome /home # on machine1 >># xfsrq -u xfshome # on machine2 >> >>but got the following error messages, >> >>Bugs to: mvw@planets.elm.net, jack@suse.cz >>setting quota for id=10091 dev=/dev/scsi/host1/bus0/target0/lun0/part7 >>setquota: invalid option -- n >>setquota: Usage: >> setquota [-u|-g] [-F quotaformat] >> >> -a|... >> setquota [-u|-g] [-F quotaformat] <-p protouser|protogroup> >> -a|... >> setquota [-u|-g] [-F quotaformat] -t >>-a|... >> setquota [-u|-g] [-F quotaformat] -T >> -a|... > > try with this patch: > > --- /usr/sbin/xfsrq Sun Jul 13 19:48:59 2003 > +++ xfsrq Sun Aug 10 15:00:31 2003 > @@ -66,7 +66,7 @@ > # blk conversion (512 -> 1024) > bsoft=`expr $bsoft / 2` > bhard=`expr $bhard / 2` > - setquota $OPTS -n $id $fs $bsoft $bhard $isoft $ihard > + setquota $OPTS $id $bsoft $bhard $isoft $ihard $fs > done > ;; > *) echo $USAGE 1>&2 > > i have been meaning to check current quota utils to see if its just > the older version i have which lacks the -n switch , or if the xfsrq > script is just broken. No it doesn't work. setting quota for id=10097 dev=/dev/scsi/host1/bus0/target0/lun0/part7 setquota: Bad block softlimit: /dev/scsi/host1/bus0/target0/lun0/part7 setquota: Usage: setquota [-u|-g] [-F quotaformat] -a|... My system_quota (xfshome) file looks as follow. fs = /dev/scsi/host1/bus0/target0/lun0/part7 0 409600 409600 512 512 fs = /dev/scsi/host1/bus0/target0/lun0/part7 10098 409600 409600 512 512 fs = /dev/scsi/host1/bus0/target0/lun0/part7 10000 409600 409600 512 512 ... Regards, Norman From owner-linux-xfs@oss.sgi.com Mon Mar 8 14:38:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Mar 2004 14:38:08 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i28Mc3KO008675 for ; Mon, 8 Mar 2004 14:38:04 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i28Mbuw9009142 for ; Mon, 8 Mar 2004 16:37:57 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i28MbsAL2307821 for ; Tue, 9 Mar 2004 09:37:54 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i28Mbp2o2250464 for linux-xfs@oss.sgi.com; Tue, 9 Mar 2004 09:37:51 +1100 (EST) Date: Tue, 9 Mar 2004 09:37:51 +1100 (EST) From: Nathan Scott Message-Id: <200403082237.i28Mbp2o2250464@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - export filemap_flush X-archive-position: 2380 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 304 Lines: 13 Fix 2.6 builds with XFS-as-a-module. Date: Mon Mar 8 14:36:03 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.6.x-xfs Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:168080a mm/filemap.c - 1.6 From owner-linux-xfs@oss.sgi.com Mon Mar 8 14:47:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Mar 2004 14:47:29 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i28MlPKO009247 for ; Mon, 8 Mar 2004 14:47:25 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i28Mkq02021122 for ; Mon, 8 Mar 2004 14:46:53 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i28MkqKe35179774 for ; Mon, 8 Mar 2004 16:46:52 -0600 (CST) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i28MkpXa819864; Mon, 8 Mar 2004 16:46:51 -0600 (CST) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id i28Mj9KW011126; Mon, 8 Mar 2004 16:45:10 -0600 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id i28Mj9r1011124; Mon, 8 Mar 2004 16:45:09 -0600 Date: Mon, 8 Mar 2004 16:45:09 -0600 From: Eric Sandeen Message-Id: <200403082245.i28Mj9r1011124@penguin.americas.sgi.com> Subject: PARTIAL TAKE 904029 - Fix process flag handling X-archive-position: 2381 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 996 Lines: 34 We previously had a possibility of corrupting process flags when restoring saved state from nested PF_FSTRANS settings, this should fix it up. Never saw a resulting bug in the wild, but demonstrated the possibility. Date: Mon Mar 8 14:45:20 PST 2004 Workarea: penguin.americas.sgi.com:/src/eric/xfs-trees/xfs-GUT Inspected by: felixb,hch The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:168082a xfs_trans.c - 1.155 - Use PFLAGS_RESTORE_FSTRANS in place of PFLAGS_RESTORE, only restore previously saved FSTRANS state. Otherwise we can lose process flags. linux-2.4/xfs_aops.c - 1.74 - Update PFLAGS_SET_NOIO macro, no saved state linux-2.6/kmem.h - 1.22 - New PFLAGS_RESTORE_FSTRANS macro to restore only FSTRANS state from saved state linux-2.4/kmem.h - 1.24 - Simplify PFLAGS_SET_NOIO macros, no need to save state New PFLAGS_RESTORE_FSTRANS macro to restore only FSTRANS state from saved state From owner-linux-xfs@oss.sgi.com Mon Mar 8 16:20:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Mar 2004 16:20:36 -0800 (PST) Received: from internalmx.vasoftware.com (internalmx.vasoftware.com [198.186.202.175]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i290KLKO015083 for ; Mon, 8 Mar 2004 16:20:21 -0800 Received: from adsl-67-123-173-11.dsl.sntc01.pacbell.net ([67.123.173.11]:61839 helo=linux-sxs.org) by internalmx.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.22 #1 (Debian)) id 1B0Uyp-0002Bf-PQ by VAauthid with fixed_plain; Mon, 08 Mar 2004 16:20:19 -0800 Message-ID: <404D0DB8.2060307@linux-sxs.org> Date: Mon, 08 Mar 2004 16:20:08 -0800 From: "Net Llama!" Organization: HAL III User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040119 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: fedora core2-test1 & XFS References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-EA-Verified: internalmx.vasoftware.com 1B0Uyp-0002Bf-PQ ccdc2adecc2af1fd54139ec73f77788c X-archive-position: 2382 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 639 Lines: 24 Yup that worked perfectly. thanks! On 03/05/04 20:29, Eric Sandeen wrote: > I believe it does, as an unsupported option - try > booting "linux xfs" at the prompt, or something like that. > > And let us know how it goes. :) > > -eric > > On Fri, 5 Mar 2004, Net Llama! wrote: > > >>Does anyone know if Fedora core2-test1 has XFS support in the installer? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 16:15:01 up 92 days, 20:54, 1 user, load average: 0.25, 0.22, 0.15 From owner-linux-xfs@oss.sgi.com Mon Mar 8 16:32:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Mar 2004 16:33:01 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i290WuKO016053 for ; Mon, 8 Mar 2004 16:32:56 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i290Wow9006335 for ; Mon, 8 Mar 2004 18:32:50 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i290WoKe35144035; Mon, 8 Mar 2004 18:32:50 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i290WoEr1616145; Mon, 8 Mar 2004 18:32:50 -0600 (CST) Date: Mon, 8 Mar 2004 18:32:50 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Net Llama! cc: linux-xfs@oss.sgi.com Subject: Re: fedora core2-test1 & XFS In-Reply-To: <404D0DB8.2060307@linux-sxs.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2383 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 363 Lines: 18 Out of curiosity, did you use the grub bootloader? -Eric On Mon, 8 Mar 2004, Net Llama! wrote: > Yup that worked perfectly. thanks! > > On 03/05/04 20:29, Eric Sandeen wrote: > > > I believe it does, as an unsupported option - try > > booting "linux xfs" at the prompt, or something like that. > > > > And let us know how it goes. :) > > > > -eric > > From owner-linux-xfs@oss.sgi.com Mon Mar 8 18:36:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Mar 2004 18:36:24 -0800 (PST) Received: from cudasrv1 (206-171-8-220.opus.com [206.171.8.220] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i292aLKO025159 for ; Mon, 8 Mar 2004 18:36:21 -0800 Received: from denis.barracudanetworks.com ([192.168.1.18]) by cudasrv1 with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Mar 2004 18:36:47 -0800 Subject: kupdated race condition From: denis Reply-To: denis@skyfulloffish.com To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Sky Full Of Fish Message-Id: <1078799673.5499.98.camel@denis.barracudanetworks.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Mon, 08 Mar 2004 18:34:34 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2004 02:36:47.0377 (UTC) FILETIME=[5E44D010:01C4057F] X-archive-position: 2384 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: denis@skyfulloffish.com Precedence: bulk X-list: linux-xfs Content-Length: 759 Lines: 25 Hi, I'm running Mandrake 9.1 (patched with the Mandrake 2.4.21-0.26 kernel) on a dual xeon machine with 2 Gb ram. It has a 3ware raid card with 2 250gb disks in mirroring mode. All filesystems are XFS. Under heavy disk io (mailserver) the kupdated process uses all cpu until the system hangs eventually. It appears to race on 1 cpu and when the second cpu begins to race the whole system hangs. It does not oops or leave anything in /var/log/messages This does not happen when mounting the partitions with the 'sync' option, however this causes severe performance problems. It also does not happen when using other (ext3) filesystems. We can not reliably reproduce this. This happens on several machines on remote locations. Any ideas? thanks, denis From owner-linux-xfs@oss.sgi.com Mon Mar 8 19:44:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Mar 2004 19:45:07 -0800 (PST) Received: from internalmx.vasoftware.com (internalmx.vasoftware.com [198.186.202.175]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i293ivKO030582 for ; Mon, 8 Mar 2004 19:44:57 -0800 Received: from adsl-67-123-173-11.dsl.sntc01.pacbell.net ([67.123.173.11]:63280 helo=linux-sxs.org) by internalmx.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.22 #1 (Debian)) id 1B0YAn-00064i-Vp by VAauthid with fixed_plain; Mon, 08 Mar 2004 19:44:54 -0800 Message-ID: <404D3DAD.5020507@linux-sxs.org> Date: Mon, 08 Mar 2004 19:44:45 -0800 From: "Net Llama!" Organization: HAL III User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040119 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: fedora core2-test1 & XFS References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-EA-Verified: internalmx.vasoftware.com 1B0YAn-00064i-Vp 80c4fcbb01ce534eea85329c1ee1a1da X-archive-position: 2385 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 1715 Lines: 52 Funny you should ask. The installer hung when it got to the point of installing Grub. There doesn't seem to be any choice in bootloaders, its Grub or, you're on your own. I guess i could have hacked LILO into place post-install, but i really wasn't in the mood for such heroics. I'm still a die-hard LILO fan, and this grub stuff just rubs me the wrong way, even if it went swimmingly. At any rate, i followed this advice: http://marc.theaimsgroup.com/?l=linux-xfs&m=107704299608539&w=2 and it appeared to get me back in business. Or so I thought, but apparently killing grub manually sends anaconda into a tila spin, and the installer self-terminates abnormally. Looks like Redhat still hasn't quite figured out this XFS concept. Upon boot it tries to run fsck.xfs which doesn't exist. That seemed to freak out the boot process a bit. At any rate, i've got a 2.6.1 kernel to play with, so i'm moderately satisfied. You SGI folks are miles ahead of Redhat on getting their distro to install properly. On 03/08/04 16:32, Eric Sandeen wrote: > Out of curiosity, did you use the grub bootloader? > > -Eric > > On Mon, 8 Mar 2004, Net Llama! wrote: > > >>Yup that worked perfectly. thanks! >> >>On 03/05/04 20:29, Eric Sandeen wrote: >> >> >>>I believe it does, as an unsupported option - try >>>booting "linux xfs" at the prompt, or something like that. >>> >>>And let us know how it goes. :) >>> >>>-eric >>> -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 19:35:01 up 93 days, 14 min, 1 user, load average: 0.14, 0.20, 0.18 From owner-linux-xfs@oss.sgi.com Mon Mar 8 19:55:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Mar 2004 19:55:22 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i293tIKO031712 for ; Mon, 8 Mar 2004 19:55:18 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i295trx0026094 for ; Mon, 8 Mar 2004 21:55:53 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i293t9Ke35137787; Mon, 8 Mar 2004 21:55:09 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i293t8Er1565021; Mon, 8 Mar 2004 21:55:08 -0600 (CST) Date: Mon, 8 Mar 2004 21:55:08 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Net Llama! cc: linux-xfs@oss.sgi.com Subject: Re: fedora core2-test1 & XFS In-Reply-To: <404D3DAD.5020507@linux-sxs.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2386 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2344 Lines: 70 Thanks for the feedback - I did not quite expect grub to work. It seems to want to access the bits on disk via the filesystem and via the block device, almost at the same time. This often does not work, because things are not coherent between the two. If you have the time, please file bugs with Red Hat on the xfs integration problems you find - xfs is not explicitly supported (well... nothing in Fedora is supported...) but it'd be nice to get these on-record. Thanks! -Eric On Mon, 8 Mar 2004, Net Llama! wrote: > Funny you should ask. The installer hung when it got to the point of > installing Grub. There doesn't seem to be any choice in bootloaders, > its Grub or, you're on your own. I guess i could have hacked LILO into > place post-install, but i really wasn't in the mood for such heroics. > I'm still a die-hard LILO fan, and this grub stuff just rubs me the > wrong way, even if it went swimmingly. > > At any rate, i followed this advice: > http://marc.theaimsgroup.com/?l=linux-xfs&m=107704299608539&w=2 > > and it appeared to get me back in business. Or so I thought, but > apparently killing grub manually sends anaconda into a tila spin, and > the installer self-terminates abnormally. > > Looks like Redhat still hasn't quite figured out this XFS concept. Upon > boot it tries to run fsck.xfs which doesn't exist. That seemed to freak > out the boot process a bit. At any rate, i've got a 2.6.1 kernel to > play with, so i'm moderately satisfied. > > You SGI folks are miles ahead of Redhat on getting their distro to > install properly. > > On 03/08/04 16:32, Eric Sandeen wrote: > > > Out of curiosity, did you use the grub bootloader? > > > > -Eric > > > > On Mon, 8 Mar 2004, Net Llama! wrote: > > > > > >>Yup that worked perfectly. thanks! > >> > >>On 03/05/04 20:29, Eric Sandeen wrote: > >> > >> > >>>I believe it does, as an unsupported option - try > >>>booting "linux xfs" at the prompt, or something like that. > >>> > >>>And let us know how it goes. :) > >>> > >>>-eric > >>> > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > L. Friedman netllama@linux-sxs.org > Linux Step-by-step & TyGeMo: http://netllama.ipfox.com > > 19:35:01 up 93 days, 14 min, 1 user, load average: 0.14, 0.20, 0.18 > From owner-linux-xfs@oss.sgi.com Mon Mar 8 19:56:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Mar 2004 19:56:18 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i293uFKO032035 for ; Mon, 8 Mar 2004 19:56:15 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 5EAA3FB839; Mon, 8 Mar 2004 21:56:10 -0600 (CST) Date: Mon, 8 Mar 2004 19:56:10 -0800 From: Chris Wedgwood To: denis Cc: linux-xfs@oss.sgi.com Subject: Re: kupdated race condition Message-ID: <20040309035610.GA670@dingdong.cryptoapps.com> References: <1078799673.5499.98.camel@denis.barracudanetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1078799673.5499.98.camel@denis.barracudanetworks.com> X-archive-position: 2387 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 342 Lines: 13 On Mon, Mar 08, 2004 at 06:34:34PM -0800, denis wrote: > I'm running Mandrake 9.1 (patched with the Mandrake 2.4.21-0.26 kernel) > on a dual xeon machine with 2 Gb ram. It has a 3ware raid card with 2 > 250gb disks in mirroring mode. All filesystems are XFS. > Any ideas? Try a recent XFS release. CVS from oss.sgi.com perhaps? --cw From owner-linux-xfs@oss.sgi.com Tue Mar 9 01:39:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Mar 2004 01:40:00 -0800 (PST) Received: from hermod.acsalaska.net (hermod.acsalaska.net [209.112.155.45]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i299dvKO007006 for ; Tue, 9 Mar 2004 01:39:57 -0800 Received: from erbenson.alaska.net (115-pm22.nwc.acsalaska.net [209.112.143.115]) by hermod.acsalaska.net (8.12.10/8.12.10) with ESMTP id i297UpHJ043431 for ; Mon, 8 Mar 2004 22:30:52 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id B800539D9 for ; Mon, 8 Mar 2004 22:30:50 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id A12C440FF35; Mon, 8 Mar 2004 22:30:50 -0900 (AKST) Date: Mon, 8 Mar 2004 22:30:50 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Quota Backup Message-ID: <20040309073050.GC2022@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <40491E66.8030802@rd.arkonnetworks.com> <20040306075311.GJ1003@plato.local.lan> <404CB95B.8050105@rd.arkonnetworks.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E13BgyNx05feLLmH" Content-Disposition: inline In-Reply-To: <404CB95B.8050105@rd.arkonnetworks.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.38; SA 2.63; spamdefang 1.93 X-archive-position: 2388 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 678 Lines: 31 --E13BgyNx05feLLmH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 08, 2004 at 10:20:11AM -0800, Norman Zhang wrote: > No it doesn't work. don't know then, works for me with debian quota 3.06-2 maybe deprecated devfs is breaking it. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --E13BgyNx05feLLmH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkBNcqoACgkQJKx7GixEevzVsACaAiFds3ckaAal79gX6hqJGLFQ Bv4AoIa0HQVRpGSUrIgj42hWiNXL0tER =ZQcR -----END PGP SIGNATURE----- --E13BgyNx05feLLmH-- From owner-linux-xfs@oss.sgi.com Tue Mar 9 02:45:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Mar 2004 02:45:59 -0800 (PST) Received: from mailgate.urz.tu-dresden.de (mailgate.urz.tu-dresden.de [141.30.66.154]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i29AjtKO010899 for ; Tue, 9 Mar 2004 02:45:56 -0800 Received: from [127.0.0.1] (helo=localhost) by mailgate.urz.tu-dresden.de with esmtp (exim-4.22) for id 1B0ekE-0001Kb-Fl; Tue, 09 Mar 2004 11:45:54 +0100 Received: from mailgate.urz.tu-dresden.de ([127.0.0.1]) by localhost (rks24 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04966-05 for ; Tue, 9 Mar 2004 11:45:54 +0100 (MET) Received: from [141.30.43.99] (helo=llhosts) by mailgate.urz.tu-dresden.de with esmtp (exim-4.22) for id 1B0ekD-0001KX-Sv; Tue, 09 Mar 2004 11:45:53 +0100 Subject: xfs with acl on kernel 2.4.25 From: Andreas Matthus To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1078829150.1599.9.camel@madeb02> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 09 Mar 2004 11:45:50 +0100 Content-Transfer-Encoding: 7bit X-TUD-Virus-Scanned: by amavisd-new at rks24.urz.tu-dresden.de X-TUD-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on rks24 X-archive-position: 2389 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Andreas.Matthus@mailbox.tu-dresden.de Precedence: bulk X-list: linux-xfs Content-Length: 262 Lines: 10 Hallo, today I wont to change form kernel 2.4.18 with xfs-patch to 2.4.25. Latest kernel have include the xfs-patch inside. Mount xfs works fine, but no acl support is possible. Can you help me to activate acl-support? best regards Andreas Matthus TU Dresden From owner-linux-xfs@oss.sgi.com Tue Mar 9 05:01:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Mar 2004 05:01:27 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i29D1AKO017005 for ; Tue, 9 Mar 2004 05:01:11 -0800 Received: from chaos.egr.duke.edu (localhost.localdomain [127.0.0.1]) by chaos.egr.duke.edu (8.12.8/8.12.8) with ESMTP id i29D14Oo022729; Tue, 9 Mar 2004 08:01:04 -0500 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.12.8/8.12.8/Submit) with ESMTP id i29D14bm022725; Tue, 9 Mar 2004 08:01:04 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Tue, 9 Mar 2004 08:01:04 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Andreas Matthus cc: linux-xfs@oss.sgi.com Subject: Re: xfs with acl on kernel 2.4.25 In-Reply-To: <1078829150.1599.9.camel@madeb02> Message-ID: References: <1078829150.1599.9.camel@madeb02> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2390 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 454 Lines: 14 On Tue, 9 Mar 2004 at 11:45am, Andreas Matthus wrote > today I wont to change form kernel 2.4.18 with xfs-patch to 2.4.25. > Latest kernel have include the xfs-patch inside. Mount xfs works fine, > but no acl support is possible. Can you help me to activate acl-support? ACLs aren't in XFS in 2.4. Grab the latest split-acl patch from oss.sgi.com and apply it to 2.4.25. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Tue Mar 9 17:35:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Mar 2004 17:35:34 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2A1ZSKO019962 for ; Tue, 9 Mar 2004 17:35:28 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2A3aAqD026585 for ; Tue, 9 Mar 2004 19:36:11 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA28953; Wed, 10 Mar 2004 12:35:19 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2A1ZGFx186180; Wed, 10 Mar 2004 12:35:17 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i2A1Yv7e001324; Wed, 10 Mar 2004 12:34:58 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i2A1YuDY001322; Wed, 10 Mar 2004 12:34:56 +1100 Date: Wed, 10 Mar 2004 12:34:56 +1100 From: Nathan Scott To: SE Linux Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and SE Linux Message-ID: <20040310013456.GC1004@frodo> References: <200403100014.03542.russell@coker.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403100014.03542.russell@coker.com.au> User-Agent: Mutt/1.5.3i X-archive-position: 2391 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1514 Lines: 40 Hi Russell, Thanks for sending this out. Couple of additions... On Wed, Mar 10, 2004 at 12:14:03AM +1100, Russell Coker wrote: > XFS defaults to an Inode size of 256 bytes and a block size of 4K on i386. These default values are platform independent. > The "security.selinux" xattr name and the data stored in it can apparently be > counted on to not fit into the <50 bytes left in a 256 byte Inode after all > the other meta-data is stored. This will mean that a new block is used for > the XATTR (which in 99.99% of all cases will be the only XATTR on the file). > > Using an extra 4K block per file is a significant waste of disk space, XFS > apparently does not support block sharing so you have 4K of disk space for 50 > bytes of data. It also amounts to a fairly significant performance hit, since there is additional I/O involved once the attributes are no longer inline. When we tweaked the ACL code to be more conscious of this issue, speedups were of the order 10x-12x IIRC. Heavy users of extended attributes should always use larger inode sizes with XFS. > If at mkfs time you make the Inode 512 bytes in size you will have enough > space for the SE Linux xattr. This will save huge amounts of space on a SE > Linux system as there will effectively be 256 bytes of overhead per file > instead of 4096. That extra inline space is also available for use by inline directory entries (and of course other extended attributes), so its not useless overhead either. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Mar 10 03:32:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 03:32:20 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2ABWDKO009309 for ; Wed, 10 Mar 2004 03:32:13 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2ABWCp8009308 for linux-xfs@oss.sgi.com; Wed, 10 Mar 2004 03:32:12 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2ABWAKQ009293 for ; Wed, 10 Mar 2004 03:32:11 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2AB7LDo008687; Wed, 10 Mar 2004 03:07:21 -0800 Date: Wed, 10 Mar 2004 03:07:21 -0800 Message-Id: <200403101107.i2AB7LDo008687@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 314] New: xfsdump doesn't work on Linux/sparc64 X-Bugzilla-Reason: AssignedTo X-archive-position: 2392 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2630 Lines: 69 http://oss.sgi.com/bugzilla/show_bug.cgi?id=314 Summary: xfsdump doesn't work on Linux/sparc64 Product: Linux XFS Version: unspecified Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: High Component: xfsdump AssignedTo: xfs-master@oss.sgi.com ReportedBy: au@hcsd.de xfsdump doesn't work on Linux/sparc64: # uname -a Linux aiken 2.4.25 #1 Tue Mar 9 10:29:58 CET 2004 sparc64 GNU/Linux # df -Pk /opt Filesystem 1024-blocks Used Available Capacity Mounted on /dev/vg00/lv_opt 257344 85340 172004 34% /opt # xfsdump -h 2> /dev/null xfsdump: version 2.2.18 (dump format 3.0) # dpkg -l xfsdump Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ ii xfsdump 2.2.18-1 Administrative utilities for the XFS filesys # xfsdump -J -F -l 0 -p 60 -f /dev/null /opt xfsdump: using file dump (drive_simple) strategy xfsdump: version 2.2.18 (dump format 3.0) - Running single-threaded xfsdump: WARNING: no session label specified xfsdump: unable to determine uuid of fs mounted at /opt: Invalid argument xfsdump: level 0 dump of aiken:/opt xfsdump: dump date: Wed Mar 10 12:03:00 2004 xfsdump: session id: e932e47c-151c-4545-9e0f-1fd1bf4a8c04 xfsdump: session label: "" xfsdump: unable to construct a file system handle for /opt: Invalid argument xfsdump: Dump Status: ERROR Kernel log shows sys32_ioctl(xfsdump:1067): Unknown cmd fd(5) cmd(40705864) arg(effff3f8) sys32_ioctl(xfsdump:1067): Unknown cmd fd(6) cmd(c01c5868) arg(efffe420) sys32_ioctl(xfsdump:1068): Unknown cmd fd(5) cmd(40705864) arg(effff3e8) sys32_ioctl(xfsdump:1068): Unknown cmd fd(6) cmd(c01c5868) arg(efffe410) Additional info: # dpkg -l libc6 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries and Timezone Please let me know if more information is needed. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 10 04:53:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 04:53:49 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2ACrUKO014680 for ; Wed, 10 Mar 2004 04:53:30 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2AClhPG020325 for ; Wed, 10 Mar 2004 06:47:43 -0600 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2AClgKe35210078; Wed, 10 Mar 2004 06:47:42 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1B137d-0004c0-00; Wed, 10 Mar 2004 06:47:41 -0600 Subject: PARTIAL TAKE 910888 - Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Wed, 10 Mar 2004 06:47:41 -0600 X-archive-position: 2393 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 445 Lines: 16 Date: Wed Mar 10 04:47:17 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: nathans,sandeen The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:168167a fs/xfs/linux-2.6/xfs_file.c - 1.99 - use ssize_t to store VOP_READ/VOP_WRITE return value fs/xfs/linux-2.4/xfs_file.c - 1.104 - use ssize_t to store VOP_READ/VOP_WRITE return value From owner-linux-xfs@oss.sgi.com Wed Mar 10 05:07:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 05:07:42 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2AD7dKO015444 for ; Wed, 10 Mar 2004 05:07:39 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2AF8Qxd019089 for ; Wed, 10 Mar 2004 07:08:26 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2AD7WKe35256388; Wed, 10 Mar 2004 07:07:32 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1B13Qq-00056m-00; Wed, 10 Mar 2004 07:07:32 -0600 Subject: PARTIAL TAKE 908809 - Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Wed, 10 Mar 2004 07:07:32 -0600 X-archive-position: 2394 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 542 Lines: 22 Date: Wed Mar 10 05:07:14 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:168168a fs/xfs/linux-2.6/xfs_buf.h - 1.91 - clarify pagebuf page lookup logic fs/xfs/linux-2.6/xfs_buf.c - 1.156 - clarify pagebuf page lookup logic fs/xfs/linux-2.4/xfs_buf.h - 1.98 - clarify pagebuf page lookup logic fs/xfs/linux-2.4/xfs_buf.c - 1.178 - clarify pagebuf page lookup logic From owner-linux-xfs@oss.sgi.com Wed Mar 10 05:32:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 05:32:17 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2ADWDKO016321 for ; Wed, 10 Mar 2004 05:32:13 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2ADWDwd016320 for linux-xfs@oss.sgi.com; Wed, 10 Mar 2004 05:32:13 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2ADWBKQ016306 for ; Wed, 10 Mar 2004 05:32:11 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2ACWurC014250; Wed, 10 Mar 2004 04:32:56 -0800 Date: Wed, 10 Mar 2004 04:32:56 -0800 Message-Id: <200403101232.i2ACWurC014250@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 314] xfsdump doesn't work on Linux/sparc64 X-Bugzilla-Reason: AssignedTo X-archive-position: 2395 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 667 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=314 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From hch@xfs.org 2004-10-03 04:32 PDT ------- No, you are not using sparc64, but a sparc32 userland with a sparc64 kernel. You need to add the xfs ioctls to the ioctl32 layer to make this work. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 10 06:00:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 06:00:25 -0800 (PST) Received: from shksmtp02.so-net.com.hk (shksmtp02.so-net.com.hk [203.99.142.22]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2AE0FKO017247 for ; Wed, 10 Mar 2004 06:00:20 -0800 Received: (qmail 2445 invoked from network); 10 Mar 2004 14:00:09 -0000 Received: from so165248.bbo165.so-net.com.hk (HELO linuxmail.org) ([203.176.165.248]) (envelope-sender ) by shksmtp02.so-net.com.hk (qmail-ldap-1.03) with SMTP for ; 10 Mar 2004 14:00:09 -0000 Message-ID: <404F1F68.30700@linuxmail.org> Date: Wed, 10 Mar 2004 22:00:08 +0800 From: Feizhou User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: XFS Mailing List Subject: mkfs under different kernels Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2396 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: feizhou@linuxmail.org Precedence: bulk X-list: linux-xfs Content-Length: 141 Lines: 5 Is there any difference between running mkfs.xfs under a 2.4 kernel and running that under a 2.6 kernel? Any benefits doing it under 2.6? From owner-linux-xfs@oss.sgi.com Wed Mar 10 06:25:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 06:25:24 -0800 (PST) Received: from shksmtp01.so-net.com.hk (pop.so-net.com.hk [203.99.142.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2AEPIKO018375 for ; Wed, 10 Mar 2004 06:25:19 -0800 Received: (qmail 11498 invoked from network); 10 Mar 2004 14:25:11 -0000 Received: from so165248.bbo165.so-net.com.hk (HELO linuxmail.org) ([203.176.165.248]) (envelope-sender ) by shksmtp01.so-net.com.hk (qmail-ldap-1.03) with SMTP for ; 10 Mar 2004 14:25:11 -0000 Message-ID: <404F2546.90904@linuxmail.org> Date: Wed, 10 Mar 2004 22:25:10 +0800 From: Feizhou User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: XFS Mailing List Subject: Re: mkfs under different kernels References: <404F1F68.30700@linuxmail.org> In-Reply-To: <404F1F68.30700@linuxmail.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2397 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: feizhou@linuxmail.org Precedence: bulk X-list: linux-xfs Content-Length: 11491 Lines: 333 Feizhou wrote: > Is there any difference between running mkfs.xfs under a 2.4 kernel and > running that under a 2.6 kernel? > > Any benefits doing it under 2.6? > > Let me add some context. I am going to conduct some benchmarks between xfs and ext3 under different configurations and I wondered if running mkfs under different kernels would affect the results. rom owner-linux-xfs@oss.sgi.com Wed Mar 10 07:14:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 07:15:12 -0800 (PST) Received: from shksmtp01.so-net.com.hk (pop.so-net.com.hk [203.99.142.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2AFEiKO020340 for ; Wed, 10 Mar 2004 07:14:45 -0800 Received: (qmail 15513 invoked from network); 10 Mar 2004 15:14:37 -0000 Received: from so165248.bbo165.so-net.com.hk (HELO linuxmail.org) ([203.176.165.248]) (envelope-sender ) by shksmtp01.so-net.com.hk (qmail-ldap-1.03) with SMTP for ; 10 Mar 2004 15:14:37 -0000 Message-ID: <404F30DD.60507@linuxmail.org> Date: Wed, 10 Mar 2004 23:14:37 +0800 From: Feizhou User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: XFS Mailing List Subject: [Fwd: ran into rare bug: "unable to verify superblock, continuing..."] Content-Type: multipart/mixed; boundary="------------080601060505010502060704" X-archive-position: 2398 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: feizhou@linuxmail.org Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. --------------080601060505010502060704 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Forwarded to list on behalf of Errikos Pitsos --------------080601060505010502060704 Content-Type: message/rfc822; name="[Fwd: Warning: could not send message for past 4 hours]" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="[Fwd: Warning: could not send message for past 4 hours]" Return-Path: Delivered-To: feizhou:linuxmail.org@linuxmail.org Received: (qmail 14181 invoked by uid 0); 10 Mar 2004 15:07:01 -0000 X-OB-Received: from unknown (205.158.62.147) by mta45-1.us4.outblaze.com; 10 Mar 2004 15:07:01 -0000 Received: from mx.leogic.com (mx.leogic.com [62.245.182.8]) by spf5-2.us4.outblaze.com (Postfix) with ESMTP id 66AD219A486 for ; Wed, 10 Mar 2004 15:06:56 +0000 (GMT) Received: from leogic.com ([192.168.41.28]) (authenticated bits=0) by mx.leogic.com (8.12.11/8.12.10) with ESMTP id i2AF8ZTg021289 (version=TLSv1/SSLv3 cipher=IDEA-CBC-SHA bits=128 verify=NO) for ; Wed, 10 Mar 2004 16:08:36 +0100 Message-ID: <404F2EFF.1020307@leogic.com> Date: Wed, 10 Mar 2004 16:06:39 +0100 From: "Errikos Pitsos {secure}" Organization: leogic User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040126 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "feizhou@linuxmail.org {unsecure}" Subject: [Fwd: Warning: could not send message for past 4 hours] X-Enigmail-Version: 0.83.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------080509090001010002010203" This is a multi-part message in MIME format. --------------080509090001010002010203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sorry don't know why, but I somehow can't write to the list, have tried three times now and get funny bounces. Can you forward this email please? thx e -------- Original Message -------- Subject: Warning: could not send message for past 4 hours Date: Wed, 10 Mar 2004 13:40:09 +0100 From: Mail Delivery Subsystem To: ep@leogic.com ********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Wed, 10 Mar 2004 09:29:31 +0100 from pD950FEA7.dip.t-dialin.net [217.80.254.167] ----- Transcript of session follows ----- 451 4.4.1 reply: read error from oss.sgi.com. ... Deferred: Connection timed out with oss.sgi.com. Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old --------------080509090001010002010203 Content-Type: message/delivery-status; name="file:///tmp/nsmail-2.tmp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///tmp/nsmail-2.tmp" Reporting-MTA: dns; mx.leogic.com Arrival-Date: Wed, 10 Mar 2004 09:29:31 +0100 Final-Recipient: RFC822; linux-xfs@oss.sgi.com Action: delayed Status: 4.4.2 Remote-MTA: DNS; oss.sgi.com Diagnostic-Code: SMTP; 451 4.4.1 reply: read error from oss.sgi.com. Last-Attempt-Date: Wed, 10 Mar 2004 13:40:09 +0100 Will-Retry-Until: Mon, 15 Mar 2004 09:29:31 +0100 --------------080509090001010002010203 Content-Type: message/rfc822; name="(null).eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="(null).eml" Return-Path: Received: from leogic.com (pD950FEA7.dip.t-dialin.net [217.80.254.167]) (authenticated bits=0) by mx.leogic.com (8.12.11/8.12.10) with ESMTP id i2A8TPl4024540 (version=TLSv1/SSLv3 cipher=IDEA-CBC-SHA bits=128 verify=NO) for ; Wed, 10 Mar 2004 09:29:31 +0100 Message-ID: <404ED170.9000601@leogic.com> Date: Wed, 10 Mar 2004 09:27:28 +0100 From: "Errikos Pitsos {secure}" Organization: leogic User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040126 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com {unsecure}" Subject: ran into rare bug: "unable to verify superblock, continuing..." X-Enigmail-Version: 0.83.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi! Seems like I ran into a known problem wrt to "unable to verify superblock, continuing..." http://oss.sgi.com/projects/xfs/faq.html#xfsmountfail I can't mount the xfs fs. I can't repair the xfs fs. Yes, this is my root partition, this is a new system I was setting up. I don't know what caused the trouble, but it seems that somehow the system was not properly unmounted. Using xfs_repai without "L" doesn't change anything. So if I can help finding that bug tell me. I am using Gentoo and had a 2.4.24-xfs-r3 on there, syslog says: Mar 10 07:56:43 leonzwei SGI XFS snapshot-2.4.23-2003-12-01_00:33_UTC with no debug enabled For some reason it seems that the XFS was not cleanly unmounted, not sure though. The system was cleanly shutdown, but I didn't find a: Mar 10 03:47:25 leonzwei Ending clean XFS mount for filesystem: ide1(22,3) in there which I had before. syslog shows these here when I try to mount the partition. Mar 10 08:03:37 leonzwei XFS: bad magic number Mar 10 08:03:37 leonzwei XFS: SB validate failed here some console output: leonzwei root # xfs_repair -nLv /dev/hdc3 Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... ........................................................................................................... .....................found candidate secondary superblock... error reading superblock 54 -- seek to offset 57982058496 failed unable to verify superblock, continuing... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... .............................................................found candidate secondary superblock... error reading superblock 54 -- seek to offset 57982058496 failed unable to verify superblock, continuing... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... .............................................................found candidate secondary superblock... error reading superblock 54 -- seek to offset 57982058496 failed unable to verify superblock, continuing... goes on for ever. here something else that I saw that you requested from somebody who had the same bug: leonzwei root # xfs_db /dev/hdc3 xfs_db: unexpected XFS SB magic number 0x1917d8b3 xfs_db: sb 0 xfs_db: p magicnum = 0x1917d8b3 blocksize = 689553475 dblocks = 12180848741608851668 rblocks = 8457844901802481315 rextents = 17089333805017595916 uuid = c005688d-587d-e4b5-7729-c2cd4e81e350 logstart = 12437974581420056107 rootino = 2035592538136216092 rbmino = 2311019282328682982 rsumino = 940638864488651459 rextsize = 4062341194 agblocks = 1795335310 agcount = 3583083788 rbmblocks = 745776455 logblocks = 2344638215 versionnum = 0xcd77 sectsize = 57419 inodesize = 22122 inopblock = 22912 fname = "q\275\347\017o;\202\376; Wed, 10 Mar 2004 07:20:17 -0800 Received: from leogic.com ([192.168.41.28]) (authenticated bits=0) by mx.leogic.com (8.12.11/8.12.10) with ESMTP id i2AE0iNA001622 (version=TLSv1/SSLv3 cipher=IDEA-CBC-SHA bits=128 verify=NO) for ; Wed, 10 Mar 2004 15:00:44 +0100 Message-ID: <404F1F18.3050107@leogic.com> Date: Wed, 10 Mar 2004 14:58:48 +0100 From: "Errikos Pitsos {secure}" Organization: leogic User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040126 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com {unsecure}" Subject: ran into rare bug: "unable to verify superblock, continuing..." X-Enigmail-Version: 0.83.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2399 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ep@leogic.com Precedence: bulk X-list: linux-xfs Content-Length: 12282 Lines: 424 Hi! Seems like I ran into a known problem wrt to "unable to verify superblock, continuing..." http://oss.sgi.com/projects/xfs/faq.html#xfsmountfail I can't mount the xfs fs. I can't repair the xfs fs. Yes, this is my root partition, this is a new system I was setting up. I don't know what caused the trouble, but it seems that somehow the system was not properly unmounted. Using xfs_repai without "L" doesn't change anything. So if I can help finding that bug tell me. I am using Gentoo and had a 2.4.24-xfs-r3 on there, syslog says: Mar 10 07:56:43 leonzwei SGI XFS snapshot-2.4.23-2003-12-01_00:33_UTC with no debug enabled For some reason it seems that the XFS was not cleanly unmounted, not sure though. The system was cleanly shutdown, but I didn't find a: Mar 10 03:47:25 leonzwei Ending clean XFS mount for filesystem: ide1(22,3) in there which I had before. syslog shows these here when I try to mount the partition. Mar 10 08:03:37 leonzwei XFS: bad magic number Mar 10 08:03:37 leonzwei XFS: SB validate failed here some console output: leonzwei root # xfs_repair -nLv /dev/hdc3 Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... ........................................................................................................... .....................found candidate secondary superblock... error reading superblock 54 -- seek to offset 57982058496 failed unable to verify superblock, continuing... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... .............................................................found candidate secondary superblock... error reading superblock 54 -- seek to offset 57982058496 failed unable to verify superblock, continuing... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... .............................................................found candidate secondary superblock... error reading superblock 54 -- seek to offset 57982058496 failed unable to verify superblock, continuing... goes on for ever. here something else that I saw that you requested from somebody who had the same bug: leonzwei root # xfs_db /dev/hdc3 xfs_db: unexpected XFS SB magic number 0x1917d8b3 xfs_db: sb 0 xfs_db: p magicnum = 0x1917d8b3 blocksize = 689553475 dblocks = 12180848741608851668 rblocks = 8457844901802481315 rextents = 17089333805017595916 uuid = c005688d-587d-e4b5-7729-c2cd4e81e350 logstart = 12437974581420056107 rootino = 2035592538136216092 rbmino = 2311019282328682982 rsumino = 940638864488651459 rextsize = 4062341194 agblocks = 1795335310 agcount = 3583083788 rbmblocks = 745776455 logblocks = 2344638215 versionnum = 0xcd77 sectsize = 57419 inodesize = 22122 inopblock = 22912 fname = "q\275\347\017o;\202\376; Wed, 10 Mar 2004 07:23:39 -0800 Received: from leogic.com ([192.168.41.28]) (authenticated bits=0) by mx.leogic.com (8.12.11/8.12.10) with ESMTP id i2AFPORH010125 (version=TLSv1/SSLv3 cipher=IDEA-CBC-SHA bits=128 verify=NO) for ; Wed, 10 Mar 2004 16:25:24 +0100 Message-ID: <404F32F0.9090009@leogic.com> Date: Wed, 10 Mar 2004 16:23:28 +0100 From: "Errikos Pitsos {secure}" Organization: leogic User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040126 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com {unsecure}" Subject: ran into rare bug: "unable to verify superblock, continuing..." X-Enigmail-Version: 0.83.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------050308000704040508080808" X-archive-position: 2400 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ep@leogic.com Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. --------------050308000704040508080808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi! Seems like I ran into a known problem wrt to "unable to verify superblock, continuing..." http://oss.sgi.com/projects/xfs/faq.html#xfsmountfail I can't mount the xfs fs. I can't repair the xfs fs. Yes, this is my root partition, this is a new system I was setting up. I don't know what caused the trouble, but it seems that somehow the system was not properly unmounted. Using xfs_repai without "L" doesn't change anything. So if I can help finding that bug tell me. I am using Gentoo and had a 2.4.24-xfs-r3 on there, syslog says: Mar 10 07:56:43 leonzwei SGI XFS snapshot-2.4.23-2003-12-01_00:33_UTC with no debug enabled For some reason it seems that the XFS was not cleanly unmounted, not sure though. The system was cleanly shutdown, but I didn't find a: Mar 10 03:47:25 leonzwei Ending clean XFS mount for filesystem: ide1(22,3) in there which I had before. syslog shows these here when I try to mount the partition. Mar 10 08:03:37 leonzwei XFS: bad magic number Mar 10 08:03:37 leonzwei XFS: SB validate failed I put the console output in a file as my email was alwyas bounced as bulk by the sgi mx. Anything else I can provide bug hunters with? erik --------------050308000704040508080808 Content-Type: text/plain; name="xfs.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs.log" here some console output: leonzwei root # xfs_repair -nLv /dev/hdc3 Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... ........................................................................................................... .....................found candidate secondary superblock... error reading superblock 54 -- seek to offset 57982058496 failed unable to verify superblock, continuing... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... .............................................................found candidate secondary superblock... error reading superblock 54 -- seek to offset 57982058496 failed unable to verify superblock, continuing... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... .............................................................found candidate secondary superblock... error reading superblock 54 -- seek to offset 57982058496 failed unable to verify superblock, continuing... goes on for ever. here something else that I saw that you requested from somebody who had the same bug: leonzwei root # xfs_db /dev/hdc3 xfs_db: unexpected XFS SB magic number 0x1917d8b3 xfs_db: sb 0 xfs_db: p magicnum = 0x1917d8b3 blocksize = 689553475 dblocks = 12180848741608851668 rblocks = 8457844901802481315 rextents = 17089333805017595916 uuid = c005688d-587d-e4b5-7729-c2cd4e81e350 logstart = 12437974581420056107 rootino = 2035592538136216092 rbmino = 2311019282328682982 rsumino = 940638864488651459 rextsize = 4062341194 agblocks = 1795335310 agcount = 3583083788 rbmblocks = 745776455 logblocks = 2344638215 versionnum = 0xcd77 sectsize = 57419 inodesize = 22122 inopblock = 22912 fname = "q\275\347\017o;\202\376; Wed, 10 Mar 2004 07:35:18 -0800 Received: from leogic.com (pD950FEA7.dip.t-dialin.net [217.80.254.167]) (authenticated bits=0) by mx.leogic.com (8.12.11/8.12.10) with ESMTP id i2A8TPl4024540 (version=TLSv1/SSLv3 cipher=IDEA-CBC-SHA bits=128 verify=NO) for ; Wed, 10 Mar 2004 09:29:31 +0100 Message-ID: <404ED170.9000601@leogic.com> Date: Wed, 10 Mar 2004 09:27:28 +0100 From: "Errikos Pitsos {secure}" Organization: leogic User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040126 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com {unsecure}" Subject: ran into rare bug: "unable to verify superblock, continuing..." X-Enigmail-Version: 0.83.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2401 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ep@leogic.com Precedence: bulk X-list: linux-xfs Content-Length: 5237 Lines: 167 Hi! Seems like I ran into a known problem wrt to "unable to verify superblock, continuing..." http://oss.sgi.com/projects/xfs/faq.html#xfsmountfail I can't mount the xfs fs. I can't repair the xfs fs. Yes, this is my root partition, this is a new system I was setting up. I don't know what caused the trouble, but it seems that somehow the system was not properly unmounted. Using xfs_repai without "L" doesn't change anything. So if I can help finding that bug tell me. I am using Gentoo and had a 2.4.24-xfs-r3 on there, syslog says: Mar 10 07:56:43 leonzwei SGI XFS snapshot-2.4.23-2003-12-01_00:33_UTC with no debug enabled For some reason it seems that the XFS was not cleanly unmounted, not sure though. The system was cleanly shutdown, but I didn't find a: Mar 10 03:47:25 leonzwei Ending clean XFS mount for filesystem: ide1(22,3) in there which I had before. syslog shows these here when I try to mount the partition. Mar 10 08:03:37 leonzwei XFS: bad magic number Mar 10 08:03:37 leonzwei XFS: SB validate failed here some console output: leonzwei root # xfs_repair -nLv /dev/hdc3 Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... ........................................................................................................... .....................found candidate secondary superblock... error reading superblock 54 -- seek to offset 57982058496 failed unable to verify superblock, continuing... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... .............................................................found candidate secondary superblock... error reading superblock 54 -- seek to offset 57982058496 failed unable to verify superblock, continuing... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... ........................................................................................................... .............................................................found candidate secondary superblock... error reading superblock 54 -- seek to offset 57982058496 failed unable to verify superblock, continuing... goes on for ever. here something else that I saw that you requested from somebody who had the same bug: leonzwei root # xfs_db /dev/hdc3 xfs_db: unexpected XFS SB magic number 0x1917d8b3 xfs_db: sb 0 xfs_db: p magicnum = 0x1917d8b3 blocksize = 689553475 dblocks = 12180848741608851668 rblocks = 8457844901802481315 rextents = 17089333805017595916 uuid = c005688d-587d-e4b5-7729-c2cd4e81e350 logstart = 12437974581420056107 rootino = 2035592538136216092 rbmino = 2311019282328682982 rsumino = 940638864488651459 rextsize = 4062341194 agblocks = 1795335310 agcount = 3583083788 rbmblocks = 745776455 logblocks = 2344638215 versionnum = 0xcd77 sectsize = 57419 inodesize = 22122 inopblock = 22912 fname = "q\275\347\017o;\202\376; Wed, 10 Mar 2004 08:39:41 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2AGVndi025833 for ; Wed, 10 Mar 2004 10:31:49 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2AGVmKe35236277; Wed, 10 Mar 2004 10:31:48 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i2AGViEq1760251; Wed, 10 Mar 2004 10:31:48 -0600 (CST) Subject: Re: mkfs under different kernels From: Eric Sandeen To: Feizhou Cc: XFS Mailing List In-Reply-To: <404F2546.90904@linuxmail.org> References: <404F1F68.30700@linuxmail.org> <404F2546.90904@linuxmail.org> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1078936304.18173.4.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 10 Mar 2004 10:31:44 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2402 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 889 Lines: 27 mkfs does query the kernel for device size, stripe info, etc. So if 2.4 returns a different answer than 2.6, that's the only difference I can see that might matter. But the short answer is that it should not make a difference. You can do a quick test; if the mkfs.xfs output does not change, then there is no difference. -Eric On Wed, 2004-03-10 at 08:25, Feizhou wrote: > Feizhou wrote: > > Is there any difference between running mkfs.xfs under a 2.4 kernel and > > running that under a 2.6 kernel? > > > > Any benefits doing it under 2.6? > > > > > > Let me add some context. I am going to conduct some benchmarks between > xfs and ext3 under different configurations and I wondered if running > mkfs under different kernels would affect the results. -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Mar 10 08:43:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 08:43:25 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2AGhFKO027826 for ; Wed, 10 Mar 2004 08:43:15 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2AGhAdi029499 for ; Wed, 10 Mar 2004 10:43:10 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2AGh9Ke35255121; Wed, 10 Mar 2004 10:43:09 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i2AGh9Eq1743015; Wed, 10 Mar 2004 10:43:09 -0600 (CST) Subject: Re: ran into rare bug: "unable to verify superblock, continuing..." From: Eric Sandeen To: Errikos Pitsos {secure} Cc: linux-xfs@oss.sgi.com In-Reply-To: <404ED170.9000601@leogic.com> References: <404ED170.9000601@leogic.com> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1078936989.18173.13.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 10 Mar 2004 10:43:09 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2403 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 46543 Lines: 941 Any chance you put your bootloader on the root partition, rather than the mbr? XFS uses block zero, as would the bootloader if you put it there. Still, not sure offhand why repair did not fix things up. On Wed, 2004-03-10 at 02:27, Errikos Pitsos {secure} wrote: > Hi! > > Seems like I ran into a known problem wrt to "unable to verify > superblock, continuing..." > http://oss.sgi.com/projects/xfs/faq.html#xfsmountfail > > I can't mount the xfs fs. > I can't repair the xfs fs. > Yes, this is my root partition, this is a new system I was setting up. > I don't know what caused the trouble, but it seems that somehow the > system was not properly unmounted. > Using xfs_repai without "L" doesn't change anything. > So if I can help finding that bug tell me. > I am using Gentoo and had a 2.4.24-xfs-r3 on there, syslog says: > Mar 10 07:56:43 leonzwei SGI XFS snapshot-2.4.23-2003-12-01_00:33_UTC > with no debug enabled > > For some reason it seems that the XFS was not cleanly unmounted, not > sure though. The system was cleanly shutdown, but I didn't find a: > Mar 10 03:47:25 leonzwei Ending clean XFS mount for filesystem: ide1(22,3) > > in there which I had before. > > > syslog shows these here when I try to mount the partition. > Mar 10 08:03:37 leonzwei XFS: bad magic number > Mar 10 08:03:37 leonzwei XFS: SB validate failed > > > > here some console output: > > leonzwei root # xfs_repair -nLv /dev/hdc3 > Phase 1 - find and verify superblock... > bad primary superblock - bad magic number !!! > > attempting to find secondary superblock... > ........................................................................................................... > > > .....................found candidate secondary superblock... > error reading superblock 54 -- seek to offset 57982058496 failed > unable to verify superblock, continuing... > ........................................................................................................... > > > ........................................................................................................... > > > ........................................................................................................... > > > ........................................................................................................... > > > ........................................................................................................... > > > ........................................................................................................... > > > ........................................................................................................... > > > ........................................................................................................... > > > ........................................................................................................... > > > .............................................................found > candidate secondary superblock... > error reading superblock 54 -- seek to offset 57982058496 failed > unable to verify superblock, continuing... > ........................................................................................................... > > > ........................................................................................................... > > > ........................................................................................................... > > > ........................................................................................................... > > > ........................................................................................................... > > > ........................................................................................................... > > > ........................................................................................................... > > > ........................................................................................................... > > > ........................................................................................................... > > > .............................................................found > candidate secondary superblock... > error reading superblock 54 -- seek to offset 57982058496 failed > unable to verify superblock, continuing... > > > goes on for ever. > > here something else that I saw that you requested from somebody who had > the same bug: > > leonzwei root # xfs_db /dev/hdc3 > xfs_db: unexpected XFS SB magic number 0x1917d8b3 > xfs_db: sb 0 > xfs_db: p > magicnum = 0x1917d8b3 > blocksize = 689553475 > dblocks = 12180848741608851668 > rblocks = 8457844901802481315 > rextents = 17089333805017595916 > uuid = c005688d-587d-e4b5-7729-c2cd4e81e350 > logstart = 12437974581420056107 > rootino = 2035592538136216092 > rbmino = 2311019282328682982 > rsumino = 940638864488651459 > rextsize = 4062341194 > agblocks = 1795335310 > agcount = 3583083788 > rbmblocks = 745776455 > logblocks = 2344638215 > versionnum = 0xcd77 > sectsize = 57419 > inodesize = 22122 > inopblock = 22912 > fname = "q\275\347\017o;\202\376 blocklog = 253 > sectlog = 155 > inodelog = 111 > inopblog = 173 > agblklog = 91 > rextslog = 155 > inprogress = 45 > imax_pct = 183 > icount = 3536497887666359542 > ifree = 15647017454152257949 > fdblocks = 15766340045555572059 > frextents = 7127039695291382717 > uquotino = 7880036713507589276 > gquotino = 3559299706880429710 > qflags = 0x5d07 > flags = 0xe9 > shared_vn = 152 > inoalignmt = 237542219 > unit = 2706140452 > width = 574901660 > dirblklog = 54 > logsectlog = 60 > logsectsize = 49029 > logsunit = 1105637059 > xfs_db: > > > anything else I can provide bug hunters with? > > erik -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 rom owner-linux-xfs@oss.sgi.com Wed Mar 10 08:45:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 08:45:14 -0800 (PST) Received: from io.goeci.com (IO.goeci.com [66.28.220.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2AGj2KO028238 for ; Wed, 10 Mar 2004 08:45:03 -0800 Subject: RE: fedora core2-test1 & XFS MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C406BD.9D1D19AC" Date: Wed, 10 Mar 2004 11:30:06 -0500 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: <3554BFA5FAE4B14FB5459D36E4F4E36203D90D@io.goeci.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: fedora core2-test1 & XFS Thread-Index: AcQFimgMYwq53b0JQ/Cefw1rP0VfMgBK/vEA From: "Murthy Kambhampaty" To: "Eric Sandeen" , "Net Llama!" Cc: X-archive-position: 2404 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: murthy.kambhampaty@goeci.com Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. ------_=_NextPart_001_01C406BD.9D1D19AC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Oops, don't forget to kill grub when you first swithc to tty2. So step 1 is: 1. During "Installing bootloader ..." a. Switch to tty2 (Ctrl-Alt-F2) b. killall grub && chown /mnt/sysimage c. /sbin/grun-install d. exit, switch to tty7 (Ctrl-Alt-F7) which is waiting with the "make boot= disk?" dialog (but seem below for more to do in tty2) e. Finish installation, reboot Installed FC2 test 1 on an old Dell box, with grub. Following are some ob= servations: 1. During "Installing bootloader ..." a. Switch to tty2 b. chown /mnt/sysimage c. /sbin/grun-install d. exit, switch to tty7 which is waiting with the "make boot disk?" dialog= (but seem below for more to do in tty2) (the rest were done from linux rescue, after the rebboot failed. You proba= bly could do them in tty2 along with step 1.) 2. Replace partition labels in /etc/grub.conf and /etc/fstab with device no= des (e.g., "LABEL=3D/" with "/dev/sda2") 3. Manually copy over xfs userspace tools from /mnt/runtime/sbin (xfs.mkfs)= and /mnt/runtime/usr/sbin (still get "missing fsck.xfs", but since XFS' mo= tto is "no more fscking boot delays" (I paraphrase), I ignore the error for= now. Needs some rc.sysinit work. 4. (This may have to be done from linux rescue, though you should be able t= o ftp or nfs over from tty2 during install) a. Copy devmap_mknod.sh from device-mapper package to /etc/init.d, chmod a= +x it b. add "post-install dm-mod /etc/init.d/devmap_mknod.sh" to /etc/modprobe.= conf (this gives an error, but isn't holding up things; the instructions fr= om device-mapper INSTALL were for old modutils and /etc/modueles.conf, need= s to be rejiggered for new ones and /etc/modprobe.conf) c. Replace LMV2 initialization with (I copied rc.sysinit to rc.sysinit.ana= conda0, and delelted the LVM initialization sections in rc.sysinit): dmsetup mknod modprobe dm-mod=20 # /etc/init.d/devmap_mknod.sh could be added here, especially if you reco= mpile dm into the kernel /sbin/lvm vgchange -ay 5. Reboot success. Probably a good idea to download latest xfs userspace r= pms and install. Sweetness ... there are still a few errors during startup (automount, smart= d), but the system is operational to my needs and is really snappy compared= to previous distros. The other big surpise was XFree86 config without has= sles on this "weird" setup: I've attached a copy of the boot log. Notably, the box is a Dell Optiplex = GXa has an integrated AGP 1x graphics controller (by nvidia) that can't be = disabled; I upgraded with an ATI Radeon 7000 (PCI). While xfree86 --config= ure worked in the past, Xconfigurator did not so it was somewhat exiting to= install RedHat 8.0 and gentoo 1.4. FC2's "firstboot" script had no proble= m with it (probably becuase it doesn't use Xconfigurator anymore, so I susp= ect this is all credit to XFree86 4.3.0, but still ...) I'll hunt down the FC2 support address to which to send this, but thought I= 'd preview here since there were some inquiries lately about FC2 on this li= st. More on hardware: Dell OptilPlex Gxa, jumpered for 300MHz CPU clock Pentium III 600 MHz (Coppermine goodness), running at 300 MHz 384 MB RAM Adaptec 29160 U160 controller Fujitsu 18 GB SCSI HDD 3x Compaq SCSI2 HDD Dell LS1528 monitor configured as VS14/15 More on disk/partition layout: grub on /dev/sda /dev/sda has 4 primary partitions as follows: root on /dev/sda2 (xfs) boot on /dev/sda1 (xfs) swap on /dev/sda3 (2xRAM) VGsys on /dev/sda4 /dev/VGsys/LVusr /dev/VGsys/LVvar /dev/VGsys/LVtmp /dev/VGsys/LVopt /dev/VGsys/LVhome /dev/md0 is RAID0 over /dev/sdc1 and /dev/sdd1; /dev/md0 is in /dev/VGdata,= meant for playing around with > -----Original Message----- > From: linux-xfs-bounce@oss.sgi.com > [mailto:linux-xfs-bounce@oss.sgi.com]On Behalf Of Eric Sandeen > Sent: Monday, March 08, 2004 10:55 PM > To: Net Llama! > Cc: linux-xfs@oss.sgi.com > Subject: Re: fedora core2-test1 & XFS >=20 >=20 > Thanks for the feedback - I did not quite expect grub > to work. It seems to want to access the bits on disk > via the filesystem and via the block device, almost at the > same time. This often does not work, because things > are not coherent between the two. >=20 > If you have the time, please file bugs with Red Hat on the xfs > integration problems you find - xfs is not explicitly supported=20 > (well... nothing in Fedora is supported...) but it'd be nice > to get these on-record. >=20 > Thanks! >=20 > -Eric >=20 > On Mon, 8 Mar 2004, Net Llama! wrote: >=20 > > Funny you should ask. The installer hung when it got to=20 > the point of=20 > > installing Grub. There doesn't seem to be any choice in=20 > bootloaders,=20 > > its Grub or, you're on your own. I guess i could have=20 > hacked LILO into=20 > > place post-install, but i really wasn't in the mood for=20 > such heroics.=20 > > I'm still a die-hard LILO fan, and this grub stuff just rubs me the=20 > > wrong way, even if it went swimmingly. > >=20 > > At any rate, i followed this advice: > > http://marc.theaimsgroup.com/?l=3Dlinux-xfs&m=3D107704299608539&w=3D2 > >=20 > > and it appeared to get me back in business. Or so I thought, but=20 > > apparently killing grub manually sends anaconda into a tila=20 > spin, and=20 > > the installer self-terminates abnormally. > >=20 > > Looks like Redhat still hasn't quite figured out this XFS=20 > concept. Upon=20 > > boot it tries to run fsck.xfs which doesn't exist. That=20 > seemed to freak=20 > > out the boot process a bit. At any rate, i've got a 2.6.1=20 > kernel to=20 > > play with, so i'm moderately satisfied. > >=20 > > You SGI folks are miles ahead of Redhat on getting their distro to=20 > > install properly. > >=20 > > On 03/08/04 16:32, Eric Sandeen wrote: > >=20 > > > Out of curiosity, did you use the grub bootloader? > > >=20 > > > -Eric > > >=20 > > > On Mon, 8 Mar 2004, Net Llama! wrote: > > >=20 > > >=20 > > >>Yup that worked perfectly. thanks! > > >> > > >>On 03/05/04 20:29, Eric Sandeen wrote: > > >> > > >> > > >>>I believe it does, as an unsupported option - try > > >>>booting "linux xfs" at the prompt, or something like that. > > >>> > > >>>And let us know how it goes. :) > > >>> > > >>>-eric > > >>> > >=20 > >=20 > > --=20 > >=20 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > L. Friedman netllama@linux-sxs.org > > Linux Step-by-step & TyGeMo:=20=09=09=20=20=20=20 http://netllama.ipfox.com >=20 > 19:35:01 up 93 days, 14 min, 1 user, load average: 0.14, 0.20, 0.18 >=20 ------_=_NextPart_001_01C406BD.9D1D19AC Content-Type: application/octet-stream; name="fc2me.messages" Content-Transfer-Encoding: base64 Content-Description: fc2me.messages Content-Disposition: attachment; filename="fc2me.messages" TWFyIDEwIDA4OjQwOjE3IGZjMm1lIHN5c2xvZ2QgMS40LjE6IHJlc3RhcnQu Ck1hciAxMCAwODo0MDoxNyBmYzJtZSBzeXNsb2c6IHN5c2xvZ2Qgc3RhcnR1 cCBzdWNjZWVkZWQKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDoga2xv Z2QgMS40LjEsIGxvZyBzb3VyY2UgPSAvcHJvYy9rbXNnIHN0YXJ0ZWQuCk1h ciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IExpbnV4IHZlcnNpb24gMi42 LjEtMS42NSAoYmhjb21waWxlQHBvcmt5LmRldmVsLnJlZGhhdC5jb20pIChn Y2MgdmVyc2lvbiAzLjMuMiAyMDA0MDExOSAoUmVkIEhhdCBMaW51eCAzLjMu Mi04KSkgIzEgRnJpIEphbiAzMCAxNzoyODo1NCBFU1QgMjAwNApNYXIgMTAg MDg6NDA6MTggZmMybWUga2VybmVsOiBCSU9TLXByb3ZpZGVkIHBoeXNpY2Fs IFJBTSBtYXA6Ck1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6ICBCSU9T LWU4MjA6IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMGEwMDAwICh1 c2FibGUpCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6ICBCSU9TLWU4 MjA6IDAwMDAwMDAwMDAwZjAwMDAgLSAwMDAwMDAwMDAwMTAwMDAwIChyZXNl cnZlZCkKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogIEJJT1MtZTgy MDogMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwMTdmZmUwMDAgKHVzYWJs ZSkKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogIEJJT1MtZTgyMDog MDAwMDAwMDAxN2ZmZTAwMCAtIDAwMDAwMDAwMTgwMDAwMDAgKHJlc2VydmVk KQpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiAgQklPUy1lODIwOiAw MDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQp Ck1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IDBNQiBISUdITUVNIGF2 YWlsYWJsZS4KTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogMzgzTUIg TE9XTUVNIGF2YWlsYWJsZS4KTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5l bDogT24gbm9kZSAwIHRvdGFscGFnZXM6IDk4MzAyCk1hciAxMCAwODo0MDox OCBmYzJtZSBrZXJuZWw6ICAgRE1BIHpvbmU6IDQwOTYgcGFnZXMsIExJRk8g YmF0Y2g6MQpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiAgIE5vcm1h bCB6b25lOiA5NDIwNiBwYWdlcywgTElGTyBiYXRjaDoxNgpNYXIgMTAgMDg6 NDA6MTggZmMybWUga2VybmVsOiAgIEhpZ2hNZW0gem9uZTogMCBwYWdlcywg TElGTyBiYXRjaDoxCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IERN SSAyLjIgcHJlc2VudC4KTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDog QUNQSSBkaXNhYmxlZCBiZWNhdXNlIHlvdXIgYmlvcyBpcyBmcm9tIDAwIGFu ZCB0b28gb2xkCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IFlvdSBj YW4gZW5hYmxlIGl0IHdpdGggYWNwaT1mb3JjZQpNYXIgMTAgMDg6NDA6MTgg ZmMybWUgc3lzbG9nOiBrbG9nZCBzdGFydHVwIHN1Y2NlZWRlZApNYXIgMTAg MDg6NDA6MTggZmMybWUga2VybmVsOiBCdWlsZGluZyB6b25lbGlzdCBmb3Ig bm9kZSA6IDAKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogS2VybmVs IGNvbW1hbmQgbGluZTogcm8gcm9vdD0vZGV2L3NkYTIgcmhnYgpNYXIgMTAg MDg6NDA6MTggZmMybWUga2VybmVsOiBJbml0aWFsaXppbmcgQ1BVIzAKTWFy IDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogUElEIGhhc2ggdGFibGUgZW50 cmllczogMjA0OCAob3JkZXIgMTE6IDE2Mzg0IGJ5dGVzKQpNYXIgMTAgMDg6 NDA6MTggZmMybWUga2VybmVsOiBEZXRlY3RlZCAyOTcuOTk5IE1IeiBwcm9j ZXNzb3IuCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IFVzaW5nIHRz YyBmb3IgaGlnaC1yZXMgdGltZXNvdXJjZQpNYXIgMTAgMDg6NDA6MTggZmMy bWUga2VybmVsOiBDb25zb2xlOiBjb2xvdXIgVkdBKyA4MHgyNQpNYXIgMTAg MDg6NDA6MTggZmMybWUga2VybmVsOiBNZW1vcnk6IDM4NDUzNmsvMzkzMjA4 ayBhdmFpbGFibGUgKDIxNjZrIGtlcm5lbCBjb2RlLCA3OTQwayByZXNlcnZl ZCwgNzM0ayBkYXRhLCAyNDRrIGluaXQsIDBrIGhpZ2htZW0pCk1hciAxMCAw ODo0MDoxOCBmYzJtZSBrZXJuZWw6IENoZWNraW5nIGlmIHRoaXMgcHJvY2Vz c29yIGhvbm91cnMgdGhlIFdQIGJpdCBldmVuIGluIHN1cGVydmlzb3IgbW9k ZS4uLiBPay4KTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogQ2FsaWJy YXRpbmcgZGVsYXkgbG9vcC4uLiA1ODcuNzcgQm9nb01JUFMKTWFyIDEwIDA4 OjQwOjE4IGZjMm1lIGtlcm5lbDogU2VjdXJpdHkgU2NhZmZvbGQgdjEuMC4w IGluaXRpYWxpemVkCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IFNF TGludXg6ICBJbml0aWFsaXppbmcuCk1hciAxMCAwODo0MDoxOCBmYzJtZSBr ZXJuZWw6IFNFTGludXg6ICBTdGFydGluZyBpbiBwZXJtaXNzaXZlIG1vZGUK TWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogVGhlcmUgaXMgYWxyZWFk eSBhIHNlY3VyaXR5IGZyYW1ld29yayBpbml0aWFsaXplZCwgcmVnaXN0ZXJf c2VjdXJpdHkgZmFpbGVkLgpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVs OiBGYWlsdXJlIHJlZ2lzdGVyaW5nIGNhcGFiaWxpdGllcyB3aXRoIHRoZSBr ZXJuZWwKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogc2VsaW51eF9y ZWdpc3Rlcl9zZWN1cml0eTogIFJlZ2lzdGVyaW5nIHNlY29uZGFyeSBtb2R1 bGUgY2FwYWJpbGl0eQpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBD YXBhYmlsaXR5IExTTSBpbml0aWFsaXplZApNYXIgMTAgMDg6NDA6MTggZmMy bWUga2VybmVsOiBEZW50cnkgY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA2 NTUzNiAob3JkZXI6IDYsIDI2MjE0NCBieXRlcykKTWFyIDEwIDA4OjQwOjE4 IGZjMm1lIGtlcm5lbDogSW5vZGUtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVz OiAzMjc2OCAob3JkZXI6IDUsIDEzMTA3MiBieXRlcykKTWFyIDEwIDA4OjQw OjE4IGZjMm1lIGtlcm5lbDogTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRy aWVzOiA1MTIgKG9yZGVyOiAwLCA0MDk2IGJ5dGVzKQpNYXIgMTAgMDg6NDA6 MTggZmMybWUga2VybmVsOiBjaGVja2luZyBpZiBpbWFnZSBpcyBpbml0cmFt ZnMuLi5pdCBpc24ndCAobm8gY3BpbyBtYWdpYyk7IGxvb2tzIGxpa2UgYW4g aW5pdHJkCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IEZyZWVpbmcg aW5pdHJkIG1lbW9yeTogNTczayBmcmVlZApNYXIgMTAgMDg6NDA6MTggZmMy bWUga2VybmVsOiBDUFU6IEwxIEkgY2FjaGU6IDE2SywgTDEgRCBjYWNoZTog MTZLCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IENQVTogTDIgY2Fj aGU6IDI1NksKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogQ1BVIHNl cmlhbCBudW1iZXIgZGlzYWJsZWQuCk1hciAxMCAwODo0MDoxOCBmYzJtZSBr ZXJuZWw6IEludGVsIG1hY2hpbmUgY2hlY2sgYXJjaGl0ZWN0dXJlIHN1cHBv cnRlZC4KTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogSW50ZWwgbWFj aGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxlZCBvbiBDUFUjMC4KTWFyIDEw IDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogQ1BVOiBJbnRlbCBQZW50aXVtIElJ SSAoQ29wcGVybWluZSkgc3RlcHBpbmcgMDMKTWFyIDEwIDA4OjQwOjE4IGZj Mm1lIGtlcm5lbDogRW5hYmxpbmcgZmFzdCBGUFUgc2F2ZSBhbmQgcmVzdG9y ZS4uLiBkb25lLgpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBFbmFi bGluZyB1bm1hc2tlZCBTSU1EIEZQVSBleGNlcHRpb24gc3VwcG9ydC4uLiBk b25lLgpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBDaGVja2luZyAn aGx0JyBpbnN0cnVjdGlvbi4uLiBPSy4KTWFyIDEwIDA4OjQwOjE4IGZjMm1l IGtlcm5lbDogUE9TSVggY29uZm9ybWFuY2UgdGVzdGluZyBieSBVTklGSVgK TWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogTkVUOiBSZWdpc3RlcmVk IHByb3RvY29sIGZhbWlseSAxNgpNYXIgMTAgMDg6NDA6MTggZmMybWUga2Vy bmVsOiBFSVNBIGJ1cyByZWdpc3RlcmVkCk1hciAxMCAwODo0MDoxOCBmYzJt ZSBrZXJuZWw6IFBDSTogUENJIEJJT1MgcmV2aXNpb24gMi4xMCBlbnRyeSBh dCAweGZjZjRlLCBsYXN0IGJ1cz0yCk1hciAxMCAwODo0MDoxOCBmYzJtZSBr ZXJuZWw6IFBDSTogVXNpbmcgY29uZmlndXJhdGlvbiB0eXBlIDEKTWFyIDEw IDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogbXRycjogdjIuMCAoMjAwMjA1MTkp Ck1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IEFDUEk6IFN1YnN5c3Rl bSByZXZpc2lvbiAyMDA0MDExNgpNYXIgMTAgMDg6NDA6MTggZmMybWUga2Vy bmVsOiBBQ1BJOiBJbnRlcnByZXRlciBkaXNhYmxlZC4KTWFyIDEwIDA4OjQw OjE4IGZjMm1lIGtlcm5lbDogTGludXggUGx1ZyBhbmQgUGxheSBTdXBwb3J0 IHYwLjk3IChjKSBBZGFtIEJlbGF5Ck1hciAxMCAwODo0MDoxOCBmYzJtZSBr ZXJuZWw6IEFDUEk6IEFDUEkgdGFibGVzIGNvbnRhaW4gbm8gUENJIElSUSBy b3V0aW5nIGVudHJpZXMKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDog UENJOiBJbnZhbGlkIEFDUEktUENJIElSUSByb3V0aW5nIHRhYmxlCk1hciAx MCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IFBDSTogUHJvYmluZyBQQ0kgaGFy ZHdhcmUKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogUENJOiBQcm9i aW5nIFBDSSBoYXJkd2FyZSAoYnVzIDAwKQpNYXIgMTAgMDg6NDA6MTggZmMy bWUga2VybmVsOiBQQ0k6IFVzaW5nIElSUSByb3V0ZXIgUElJWC9JQ0ggWzgw ODYvNzExMF0gYXQgMDAwMDowMDowNy4wCk1hciAxMCAwODo0MDoxOCBmYzJt ZSBrZXJuZWw6IE1hY2hpbmUgY2hlY2sgZXhjZXB0aW9uIHBvbGxpbmcgdGlt ZXIgc3RhcnRlZC4KTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogYXBt OiBCSU9TIHZlcnNpb24gMS4yIEZsYWdzIDB4MDMgKERyaXZlciB2ZXJzaW9u IDEuMTZhYykKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogVG90YWwg SHVnZVRMQiBtZW1vcnkgYWxsb2NhdGVkLCAwCk1hciAxMCAwODo0MDoxOCBm YzJtZSBrZXJuZWw6IFZGUzogRGlzayBxdW90YXMgZHF1b3RfNi41LjEKTWFy IDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogU0VMaW51eDogIFJlZ2lzdGVy aW5nIG5ldGZpbHRlciBob29rcwpNYXIgMTAgMDg6NDA6MTggZmMybWUga2Vy bmVsOiBJbml0aWFsaXppbmcgQ3J5cHRvZ3JhcGhpYyBBUEkKTWFyIDEwIDA4 OjQwOjE4IGZjMm1lIGtlcm5lbDogTGltaXRpbmcgZGlyZWN0IFBDSS9QQ0kg dHJhbnNmZXJzLgpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBwY2lf aG90cGx1ZzogUENJIEhvdCBQbHVnIFBDSSBDb3JlIHZlcnNpb246IDAuNQpN YXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBpc2FwbnA6IFNjYW5uaW5n IGZvciBQblAgY2FyZHMuLi4KTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5l bDogaXNhcG5wOiBDYXJkICdDUzQyMzZCJwpNYXIgMTAgMDg6NDA6MTggZmMy bWUga2VybmVsOiBpc2FwbnA6IDEgUGx1ZyAmIFBsYXkgY2FyZCBkZXRlY3Rl ZCB0b3RhbApNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBwdHk6IDIw NDggVW5peDk4IHB0eXMgY29uZmlndXJlZApNYXIgMTAgMDg6NDA6MTggZmMy bWUga2VybmVsOiBSZWFsIFRpbWUgQ2xvY2sgRHJpdmVyIHYxLjEyCk1hciAx MCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IExpbnV4IGFncGdhcnQgaW50ZXJm YWNlIHYwLjEwMCAoYykgRGF2ZSBKb25lcwpNYXIgMTAgMDg6NDA6MTggZmMy bWUga2VybmVsOiBhZ3BnYXJ0OiBEZXRlY3RlZCBhbiBJbnRlbCA0NDBMWCBD aGlwc2V0LgpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBhZ3BnYXJ0 OiBNYXhpbXVtIG1haW4gbWVtb3J5IHRvIHVzZSBmb3IgYWdwIG1lbW9yeTog MzIxTQpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBhZ3BnYXJ0OiBB R1AgYXBlcnR1cmUgaXMgNjRNIEAgMHhmMDAwMDAwMApNYXIgMTAgMDg6NDA6 MTggZmMybWUga2VybmVsOiBTZXJpYWw6IDgyNTAvMTY1NTAgZHJpdmVyICRS ZXZpc2lvbjogMS45MCAkIDggcG9ydHMsIElSUSBzaGFyaW5nIGVuYWJsZWQK TWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogdHR5UzAgYXQgSS9PIDB4 M2Y4IChpcnEgPSA0KSBpcyBhIDE2NTUwQQpNYXIgMTAgMDg6NDA6MTggZmMy bWUga2VybmVsOiB0dHlTMSBhdCBJL08gMHgyZjggKGlycSA9IDMpIGlzIGEg MTY1NTBBCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IFJBTURJU0sg ZHJpdmVyIGluaXRpYWxpemVkOiAxNiBSQU0gZGlza3Mgb2YgODE5Mksgc2l6 ZSAxMDI0IGJsb2Nrc2l6ZQpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVs OiBVbmlmb3JtIE11bHRpLVBsYXRmb3JtIEUtSURFIGRyaXZlciBSZXZpc2lv bjogNy4wMGFscGhhMgpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBp ZGU6IEFzc3VtaW5nIDMzTUh6IHN5c3RlbSBidXMgc3BlZWQgZm9yIFBJTyBt b2Rlczsgb3ZlcnJpZGUgd2l0aCBpZGVidXM9eHgKTWFyIDEwIDA4OjQwOjE4 IGZjMm1lIGtlcm5lbDogUElJWDQ6IElERSBjb250cm9sbGVyIGF0IFBDSSBz bG90IDAwMDA6MDA6MDcuMQpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVs OiBQSUlYNDogY2hpcHNldCByZXZpc2lvbiAxCk1hciAxMCAwODo0MDoxOCBm YzJtZSBrZXJuZWw6IFBJSVg0OiBub3QgMTAwJSUgbmF0aXZlIG1vZGU6IHdp bGwgcHJvYmUgaXJxcyBsYXRlcgpNYXIgMTAgMDg6NDA6MTggZmMybWUga2Vy bmVsOiAgICAgaWRlMTogQk0tRE1BIGF0IDB4ZmZhOC0weGZmYWYsIEJJT1Mg c2V0dGluZ3M6IGhkYzpETUEsIGhkZDpwaW8KTWFyIDEwIDA4OjQwOjE4IGZj Mm1lIGtlcm5lbDogaGRjOiBUT1NISUJBIENELVJPTSBYTS02MjAyQiwgQVRB UEkgQ0QvRFZELVJPTSBkcml2ZQpNYXIgMTAgMDg6NDA6MTggZmMybWUga2Vy bmVsOiBVc2luZyBhbnRpY2lwYXRvcnkgaW8gc2NoZWR1bGVyCk1hciAxMCAw ODo0MDoxOCBmYzJtZSBrZXJuZWw6IGlkZTEgYXQgMHgxNzAtMHgxNzcsMHgz NzYgb24gaXJxIDE1Ck1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IGlk ZS1mbG9wcHkgZHJpdmVyIDAuOTkubmV3aWRlCk1hciAxMCAwODo0MDoxOCBm YzJtZSBrZXJuZWw6IG1pY2U6IFBTLzIgbW91c2UgZGV2aWNlIGNvbW1vbiBm b3IgYWxsIG1pY2UKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogc2Vy aW86IGk4MDQyIEFVWCBwb3J0IGF0IDB4NjAsMHg2NCBpcnEgMTIKTWFyIDEw IDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogaW5wdXQ6IFBTLzIgR2VuZXJpYyBN b3VzZSBvbiBpc2EwMDYwL3NlcmlvMQpNYXIgMTAgMDg6NDA6MTggZmMybWUg a2VybmVsOiBzZXJpbzogaTgwNDIgS0JEIHBvcnQgYXQgMHg2MCwweDY0IGly cSAxCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IGlucHV0OiBBVCBU cmFuc2xhdGVkIFNldCAyIGtleWJvYXJkIG9uIGlzYTAwNjAvc2VyaW8wCk1h ciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IG1kOiBtZCBkcml2ZXIgMC45 MC4wIE1BWF9NRF9ERVZTPTI1NiwgTURfU0JfRElTS1M9MjcKTWFyIDEwIDA4 OjQwOjE4IGZjMm1lIGtlcm5lbDogTkVUOiBSZWdpc3RlcmVkIHByb3RvY29s IGZhbWlseSAyCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IElQOiBy b3V0aW5nIGNhY2hlIGhhc2ggdGFibGUgb2YgMTAyNCBidWNrZXRzLCAzMkti eXRlcwpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBUQ1A6IEhhc2gg dGFibGVzIGNvbmZpZ3VyZWQgKGVzdGFibGlzaGVkIDMyNzY4IGJpbmQgOTM2 MikKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogSW5pdGlhbGl6aW5n IElQc2VjIG5ldGxpbmsgc29ja2V0Ck1hciAxMCAwODo0MDoxOCBmYzJtZSBr ZXJuZWw6IE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMQpNYXIg MTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBORVQ6IFJlZ2lzdGVyZWQgcHJv dG9jb2wgZmFtaWx5IDE3Ck1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6 IG1kOiBBdXRvZGV0ZWN0aW5nIFJBSUQgYXJyYXlzLgpNYXIgMTAgMDg6NDA6 MTggZmMybWUga2VybmVsOiBtZDogYXV0b3J1biAuLi4KTWFyIDEwIDA4OjQw OjE4IGZjMm1lIGtlcm5lbDogbWQ6IC4uLiBhdXRvcnVuIERPTkUuCk1hciAx MCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IFJBTURJU0s6IENvbXByZXNzZWQg aW1hZ2UgZm91bmQgYXQgYmxvY2sgMApNYXIgMTAgMDg6NDA6MTggZmMybWUg a2VybmVsOiBWRlM6IE1vdW50ZWQgcm9vdCAoZXh0MiBmaWxlc3lzdGVtKS4K TWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogU0NTSSBzdWJzeXN0ZW0g aW5pdGlhbGl6ZWQKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogUENJ OiBGb3VuZCBJUlEgMTEgZm9yIGRldmljZSAwMDAwOjAyOjBhLjAKTWFyIDEw IDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogUENJOiBTaGFyaW5nIElSUSAxMSB3 aXRoIDAwMDA6MDA6MDcuMgpNYXIgMTAgMDg6NDA6MTggZmMybWUgaXJxYmFs YW5jZTogaXJxYmFsYW5jZSBzdGFydHVwIHN1Y2NlZWRlZApNYXIgMTAgMDg6 NDA6MTggZmMybWUga2VybmVsOiBQQ0k6IFNoYXJpbmcgSVJRIDExIHdpdGgg MDAwMDowMDoxMS4wCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IHNj c2kwIDogQWRhcHRlYyBBSUM3WFhYIEVJU0EvVkxCL1BDSSBTQ1NJIEhCQSBE UklWRVIsIFJldiA2LjIuMzYKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5l bDogICAgICAgICA8QWRhcHRlYyAyOTE2MCBVbHRyYTE2MCBTQ1NJIGFkYXB0 ZXI+Ck1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6ICAgICAgICAgYWlj Nzg5MjogVWx0cmExNjAgV2lkZSBDaGFubmVsIEEsIFNDU0kgSWQ9NywgMzIv MjUzIFNDQnMKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogCk1hciAx MCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IChzY3NpMDpBOjApOiAxNjAuMDAw TUIvcyB0cmFuc2ZlcnMgKDgwLjAwME1IeiBEVCwgb2Zmc2V0IDEyNywgMTZi aXQpCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IChzY3NpMDpBOjIp OiAxMC4wMDBNQi9zIHRyYW5zZmVycyAoMTAuMDAwTUh6LCBvZmZzZXQgMTUp Ck1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IChzY3NpMDpBOjQpOiAx MC4wMDBNQi9zIHRyYW5zZmVycyAoMTAuMDAwTUh6LCBvZmZzZXQgMTUpCk1h ciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IChzY3NpMDpBOjUpOiAxMC4w MDBNQi9zIHRyYW5zZmVycyAoMTAuMDAwTUh6LCBvZmZzZXQgMTUpCk1hciAx MCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6ICAgVmVuZG9yOiBGVUpJVFNVICAg TW9kZWw6IE1BSjMxODJNUCAgICAgICAgIFJldjogNTUwOQpNYXIgMTAgMDg6 NDA6MTkgZmMybWUga2VybmVsOiAgIFR5cGU6ICAgRGlyZWN0LUFjY2VzcyAg ICAgICAgICAgICAgICAgICAgICBBTlNJIFNDU0kgcmV2aXNpb246IDAzCk1h ciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IHNjc2kwOkE6MDowOiBUYWdn ZWQgUXVldWluZyBlbmFibGVkLiAgRGVwdGggNApNYXIgMTAgMDg6NDA6MTkg ZmMybWUga2VybmVsOiBTQ1NJIGRldmljZSBzZGE6IDM1NTY2NDc4IDUxMi1i eXRlIGhkd3Igc2VjdG9ycyAoMTgyMTAgTUIpCk1hciAxMCAwODo0MDoxOSBm YzJtZSBrZXJuZWw6IFNDU0kgZGV2aWNlIHNkYTogZHJpdmUgY2FjaGU6IHdy aXRlIGJhY2sKTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogIHNkYTog c2RhMSBzZGEyIHNkYTMgc2RhNApNYXIgMTAgMDg6NDA6MTkgZmMybWUga2Vy bmVsOiBBdHRhY2hlZCBzY3NpIGRpc2sgc2RhIGF0IHNjc2kwLCBjaGFubmVs IDAsIGlkIDAsIGx1biAwCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6 ICAgVmVuZG9yOiBTRUFHQVRFICAgTW9kZWw6IFNUMTUyMzBOICAgICAgICAg IFJldjogMDYzOApNYXIgMTAgMDg6NDA6MTkgZmMybWUga2VybmVsOiAgIFR5 cGU6ICAgRGlyZWN0LUFjY2VzcyAgICAgICAgICAgICAgICAgICAgICBBTlNJ IFNDU0kgcmV2aXNpb246IDAyCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJu ZWw6IHNjc2kwOkE6MjowOiBUYWdnZWQgUXVldWluZyBlbmFibGVkLiAgRGVw dGggNApNYXIgMTAgMDg6NDA6MTkgZmMybWUga2VybmVsOiBTQ1NJIGRldmlj ZSBzZGI6IDgzODY3MzMgNTEyLWJ5dGUgaGR3ciBzZWN0b3JzICg0Mjk0IE1C KQpNYXIgMTAgMDg6NDA6MTkgZmMybWUga2VybmVsOiBTQ1NJIGRldmljZSBz ZGI6IGRyaXZlIGNhY2hlOiB3cml0ZSB0aHJvdWdoCk1hciAxMCAwODo0MDox OSBmYzJtZSBrZXJuZWw6ICBzZGI6IHNkYjEKTWFyIDEwIDA4OjQwOjE5IGZj Mm1lIGtlcm5lbDogQXR0YWNoZWQgc2NzaSBkaXNrIHNkYiBhdCBzY3NpMCwg Y2hhbm5lbCAwLCBpZCAyLCBsdW4gMApNYXIgMTAgMDg6NDA6MTkgZmMybWUg a2VybmVsOiAgIFZlbmRvcjogU0VBR0FURSAgIE1vZGVsOiBTVDE1MjMwTiAg ICAgICAgICBSZXY6IDA2MzgKTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5l bDogICBUeXBlOiAgIERpcmVjdC1BY2Nlc3MgICAgICAgICAgICAgICAgICAg ICAgQU5TSSBTQ1NJIHJldmlzaW9uOiAwMgpNYXIgMTAgMDg6NDA6MTkgZmMy bWUga2VybmVsOiBzY3NpMDpBOjQ6MDogVGFnZ2VkIFF1ZXVpbmcgZW5hYmxl ZC4gIERlcHRoIDQKTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogU0NT SSBkZXZpY2Ugc2RjOiA4Mzg2NzMzIDUxMi1ieXRlIGhkd3Igc2VjdG9ycyAo NDI5NCBNQikKTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogU0NTSSBk ZXZpY2Ugc2RjOiBkcml2ZSBjYWNoZTogd3JpdGUgdGhyb3VnaApNYXIgMTAg MDg6NDA6MTkgZmMybWUga2VybmVsOiAgc2RjOiBzZGMxCk1hciAxMCAwODo0 MDoxOSBmYzJtZSBrZXJuZWw6IEF0dGFjaGVkIHNjc2kgZGlzayBzZGMgYXQg c2NzaTAsIGNoYW5uZWwgMCwgaWQgNCwgbHVuIDAKTWFyIDEwIDA4OjQwOjE5 IGZjMm1lIGtlcm5lbDogICBWZW5kb3I6IFNFQUdBVEUgICBNb2RlbDogU1Qx NTIzME4gICAgICAgICAgUmV2OiAwNjM4Ck1hciAxMCAwODo0MDoxOSBmYzJt ZSBrZXJuZWw6ICAgVHlwZTogICBEaXJlY3QtQWNjZXNzICAgICAgICAgICAg ICAgICAgICAgIEFOU0kgU0NTSSByZXZpc2lvbjogMDIKTWFyIDEwIDA4OjQw OjE5IGZjMm1lIGtlcm5lbDogc2NzaTA6QTo1OjA6IFRhZ2dlZCBRdWV1aW5n IGVuYWJsZWQuICBEZXB0aCA0Ck1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJu ZWw6IFNDU0kgZGV2aWNlIHNkZDogODM4NjczMyA1MTItYnl0ZSBoZHdyIHNl Y3RvcnMgKDQyOTQgTUIpCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6 IFNDU0kgZGV2aWNlIHNkZDogZHJpdmUgY2FjaGU6IHdyaXRlIHRocm91Z2gK TWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogIHNkZDogc2RkMQpNYXIg MTAgMDg6NDA6MTkgZmMybWUga2VybmVsOiBBdHRhY2hlZCBzY3NpIGRpc2sg c2RkIGF0IHNjc2kwLCBjaGFubmVsIDAsIGlkIDUsIGx1biAwCk1hciAxMCAw ODo0MDoxOSBmYzJtZSBrZXJuZWw6IFNHSSBYRlMgd2l0aCBBQ0xzLCBsYXJn ZSBibG9jayBudW1iZXJzLCBubyBkZWJ1ZyBlbmFibGVkCk1hciAxMCAwODo0 MDoxOSBmYzJtZSBrZXJuZWw6IFNHSSBYRlMgUXVvdGEgTWFuYWdlbWVudCBz dWJzeXN0ZW0KTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogWEZTIG1v dW50aW5nIGZpbGVzeXN0ZW0gc2RhMgpNYXIgMTAgMDg6NDA6MTkgZmMybWUg a2VybmVsOiBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiAyNDRrIGZy ZWVkCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IGRyaXZlcnMvdXNi L2NvcmUvdXNiLmM6IHJlZ2lzdGVyZWQgbmV3IGRyaXZlciB1c2JmcwpNYXIg MTAgMDg6NDA6MTkgZmMybWUga2VybmVsOiBkcml2ZXJzL3VzYi9jb3JlL3Vz Yi5jOiByZWdpc3RlcmVkIG5ldyBkcml2ZXIgaHViCk1hciAxMCAwODo0MDox OSBmYzJtZSBrZXJuZWw6IGRyaXZlcnMvdXNiL2hvc3QvdWhjaS1oY2QuYzog VVNCIFVuaXZlcnNhbCBIb3N0IENvbnRyb2xsZXIgSW50ZXJmYWNlIGRyaXZl ciB2Mi4xCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IFBDSTogRm91 bmQgSVJRIDExIGZvciBkZXZpY2UgMDAwMDowMDowNy4yCk1hciAxMCAwODo0 MDoxOSBmYzJtZSBrZXJuZWw6IFBDSTogU2hhcmluZyBJUlEgMTEgd2l0aCAw MDAwOjAwOjExLjAKTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogUENJ OiBTaGFyaW5nIElSUSAxMSB3aXRoIDAwMDA6MDI6MGEuMApNYXIgMTAgMDg6 NDA6MTkgZmMybWUga2VybmVsOiB1aGNpX2hjZCAwMDAwOjAwOjA3LjI6IFVI Q0kgSG9zdCBDb250cm9sbGVyCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJu ZWw6IHVoY2lfaGNkIDAwMDA6MDA6MDcuMjogaXJxIDExLCBpbyBiYXNlIDAw MDBjY2UwCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IHVoY2lfaGNk IDAwMDA6MDA6MDcuMjogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWdu ZWQgYnVzIG51bWJlciAxCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6 IGh1YiAxLTA6MS4wOiBVU0IgaHViIGZvdW5kCk1hciAxMCAwODo0MDoxOSBm YzJtZSBrZXJuZWw6IGh1YiAxLTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkCk1h ciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IGRldmljZS1tYXBwZXI6IDQu MC4wLWlvY3RsICgyMDAzLTA2LTA0KSBpbml0aWFsaXNlZDogZG1AdWsuc2lz dGluYS5jb20KTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogbG9vcDog bG9hZGVkIChtYXggOCBkZXZpY2VzKQpNYXIgMTAgMDg6NDA6MTkgZmMybWUg a2VybmVsOiBoZGM6IEFUQVBJIDMyWCBDRC1ST00gZHJpdmUsIDI1NmtCIENh Y2hlLCBETUEKTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogVW5pZm9y bSBDRC1ST00gZHJpdmVyIFJldmlzaW9uOiAzLjIwCk1hciAxMCAwODo0MDox OSBmYzJtZSBrZXJuZWw6IEFkZGluZyA3ODcxNzZrIHN3YXAgb24gL2Rldi9z ZGEzLiAgUHJpb3JpdHk6LTEgZXh0ZW50czoxCk1hciAxMCAwODo0MDoxOSBm YzJtZSBrZXJuZWw6IFhGUyBtb3VudGluZyBmaWxlc3lzdGVtIHNkYTEKTWFy IDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogWEZTIG1vdW50aW5nIGZpbGVz eXN0ZW0gZG0tNQpNYXIgMTAgMDg6NDA6MTkgZmMybWUga2VybmVsOiBYRlMg bW91bnRpbmcgZmlsZXN5c3RlbSBkbS0zCk1hciAxMCAwODo0MDoxOSBmYzJt ZSBrZXJuZWw6IFhGUyBtb3VudGluZyBmaWxlc3lzdGVtIGRtLTQKTWFyIDEw IDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogWEZTIG1vdW50aW5nIGZpbGVzeXN0 ZW0gZG0tMQpNYXIgMTAgMDg6NDA6MTkgZmMybWUga2VybmVsOiBYRlMgbW91 bnRpbmcgZmlsZXN5c3RlbSBkbS0yCk1hciAxMCAwODo0MDoxOSBmYzJtZSBr ZXJuZWw6IFtkcm1dIEluaXRpYWxpemVkIHJhZGVvbiAxLjkuMCAyMDAyMDgy OCBvbiBtaW5vciAwCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IFBD STogRm91bmQgSVJRIDEwIGZvciBkZXZpY2UgMDAwMDowMDowZS4wCk1hciAx MCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IGF0a2JkLmM6IFVua25vd24ga2V5 IHJlbGVhc2VkICh0cmFuc2xhdGVkIHNldCAyLCBjb2RlIDB4N2Egb24gaXNh MDA2MC9zZXJpbzApLgpNYXIgMTAgMDg6NDA6MTkgZmMybWUga2VybmVsOiBh dGtiZC5jOiBUaGlzIGlzIGFuIFhGcmVlODYgYnVnLiBJdCBzaG91bGRuJ3Qg YWNjZXNzIGhhcmR3YXJlIGRpcmVjdGx5LgpNYXIgMTAgMDg6NDA6MTkgZmMy bWUga2VybmVsOiBhdGtiZC5jOiBVbmtub3duIGtleSByZWxlYXNlZCAodHJh bnNsYXRlZCBzZXQgMiwgY29kZSAweDdhIG9uIGlzYTAwNjAvc2VyaW8wKS4K TWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogYXRrYmQuYzogVGhpcyBp cyBhbiBYRnJlZTg2IGJ1Zy4gSXQgc2hvdWxkbid0IGFjY2VzcyBoYXJkd2Fy ZSBkaXJlY3RseS4KTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogcXVv dGFvbjogbnVtZXJpY2FsIHN5c2N0bCA1IDE2IDggaXMgb2Jzb2xldGUuCk1h ciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IElBLTMyIE1pY3JvY29kZSBV cGRhdGUgRHJpdmVyOiB2MS4xMyA8dGlncmFuQHZlcml0YXMuY29tPgpNYXIg MTAgMDg6NDA6MTkgZmMybWUga2VybmVsOiBtaWNyb2NvZGU6IENQVTAgdXBk YXRlZCBmcm9tIHJldmlzaW9uIDB4MCB0byAweDEzLCBkYXRlID0gMDIwNjIw MDEgCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IGt1ZHp1OiBudW1l cmljYWwgc3lzY3RsIDEgMjMgaXMgb2Jzb2xldGUuCk1hciAxMCAwODo0MDox OSBmYzJtZSBrZXJuZWw6IHBhcnBvcnQwOiBQQy1zdHlsZSBhdCAweDM3OCAo MHg3NzgpIFtQQ1NQUCxUUklTVEFURSxFUFBdCk1hciAxMCAwODo0MDoxOSBm YzJtZSBrZXJuZWw6IHBhcnBvcnQwOiBpcnEgNyBkZXRlY3RlZApNYXIgMTAg MDg6NDA6MTkgZmMybWUga2VybmVsOiBBdHRhY2hlZCBzY3NpIGdlbmVyaWMg c2cwIGF0IHNjc2kwLCBjaGFubmVsIDAsIGlkIDAsIGx1biAwLCAgdHlwZSAw Ck1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IEF0dGFjaGVkIHNjc2kg Z2VuZXJpYyBzZzEgYXQgc2NzaTAsIGNoYW5uZWwgMCwgaWQgMiwgbHVuIDAs ICB0eXBlIDAKTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogQXR0YWNo ZWQgc2NzaSBnZW5lcmljIHNnMiBhdCBzY3NpMCwgY2hhbm5lbCAwLCBpZCA0 LCBsdW4gMCwgIHR5cGUgMApNYXIgMTAgMDg6NDA6MTkgZmMybWUga2VybmVs OiBBdHRhY2hlZCBzY3NpIGdlbmVyaWMgc2czIGF0IHNjc2kwLCBjaGFubmVs IDAsIGlkIDUsIGx1biAwLCAgdHlwZSAwCk1hciAxMCAwODo0MDoxOSBmYzJt ZSBrZXJuZWw6IGluc2VydGluZyBmbG9wcHkgZHJpdmVyIGZvciAyLjYuMS0x LjY1Ck1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IEZsb3BweSBkcml2 ZShzKTogZmQwIGlzIDEuNDRNCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJu ZWw6IEZEQyAwIGlzIGEgTmF0aW9uYWwgU2VtaWNvbmR1Y3RvciBQQzg3MzA2 Ck1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IGt1ZHp1OiBudW1lcmlj YWwgc3lzY3RsIDEgNDkgaXMgb2Jzb2xldGUuCk1hciAxMCAwODo0MDoxOSBm YzJtZSBrZXJuZWw6IFBDSTogRm91bmQgSVJRIDExIGZvciBkZXZpY2UgMDAw MDowMDoxMS4wCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IFBDSTog U2hhcmluZyBJUlEgMTEgd2l0aCAwMDAwOjAwOjA3LjIKTWFyIDEwIDA4OjQw OjE5IGZjMm1lIGtlcm5lbDogUENJOiBTaGFyaW5nIElSUSAxMSB3aXRoIDAw MDA6MDI6MGEuMApNYXIgMTAgMDg6NDA6MTkgZmMybWUga2VybmVsOiAzYzU5 eDogRG9uYWxkIEJlY2tlciBhbmQgb3RoZXJzLiB3d3cuc2N5bGQuY29tL25l dHdvcmsvdm9ydGV4Lmh0bWwKTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5l bDogMDAwMDowMDoxMS4wOiAzQ29tIFBDSSAzYzkwNSBCb29tZXJhbmcgMTAw YmFzZVR4IGF0IDB4Y2M4MC4gVmVycyBMSzEuMS4xOQpNYXIgMTAgMDg6NDA6 MTkgZmMybWUga2VybmVsOiAgKioqSU5WQUxJRCBDSEVDS1NVTSAwMDNlKioq IDw3PmRpdmVydDogYWxsb2NhdGluZyBkaXZlcnRfYmxrIGZvciBldGgwCk1h ciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IGV0aDA6IERyb3BwaW5nIE5F VElGX0ZfU0cgc2luY2Ugbm8gY2hlY2tzdW0gZmVhdHVyZS4KTWFyIDEwIDA4 OjQwOjE5IGZjMm1lIGtlcm5lbDoga3VkenU6IG51bWVyaWNhbCBzeXNjdGwg MSA0OSBpcyBvYnNvbGV0ZS4KTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5l bDogaXBfdGFibGVzOiAoQykgMjAwMC0yMDAyIE5ldGZpbHRlciBjb3JlIHRl YW0KTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogaXBfY29ubnRyYWNr IHZlcnNpb24gMi4xICgzMDcxIGJ1Y2tldHMsIDI0NTY4IG1heCkgLSAzMjQg Ynl0ZXMgcGVyIGNvbm50cmFjawpNYXIgMTAgMDg6NDA6MTkgZmMybWUgcG9y dG1hcDogcG9ydG1hcCBzdGFydHVwIHN1Y2NlZWRlZApNYXIgMTAgMDg6NDA6 MjAgZmMybWUgcnBjLnN0YXRkWzEwMzFdOiBWZXJzaW9uIDEuMC42IFN0YXJ0 aW5nCk1hciAxMCAwODo0MDoyMCBmYzJtZSBuZnNsb2NrOiBycGMuc3RhdGQg c3RhcnR1cCBzdWNjZWVkZWQKTWFyIDEwIDA4OjQwOjE3IGZjMm1lIGlmdXA6 ICBkb25lLiAKTWFyIDEwIDA4OjQwOjE3IGZjMm1lIG5ldHdvcms6IEJyaW5n aW5nIHVwIGludGVyZmFjZSBldGgwOiAgc3VjY2VlZGVkIApNYXIgMTAgMDg6 NDA6MjAgZmMybWUgcmFuZG9tOiBJbml0aWFsaXppbmcgcmFuZG9tIG51bWJl ciBnZW5lcmF0b3I6ICBzdWNjZWVkZWQKTWFyIDEwIDA4OjQwOjIwIGZjMm1l IHJjOiBTdGFydGluZyBwY21jaWE6ICBzdWNjZWVkZWQKTWFyIDEwIDA4OjQw OjIwIGZjMm1lIG5ldGZzOiBNb3VudGluZyBvdGhlciBmaWxlc3lzdGVtczog IHN1Y2NlZWRlZApNYXIgMTAgMDg6NDA6MjEgZmMybWUgYXBtZFsxMDg2XTog VmVyc2lvbiAzLjAuMiAoQVBNIEJJT1MgMS4yLCBMaW51eCBkcml2ZXIgMS4x NmFjKQpNYXIgMTAgMDg6NDA6MjEgZmMybWUgYXBtZDogYXBtZCBzdGFydHVw IHN1Y2NlZWRlZApNYXIgMTAgMDg6NDA6MjEgZmMybWUgYXV0b2ZzOiBhdXRv bW91bnQgc3RhcnR1cCBzdWNjZWVkZWQKTWFyIDEwIDA4OjQwOjIxIGZjMm1l IHNtYXJ0ZFsxMTI0XTogc21hcnRkIHZlcnNpb24gNS4yMSBDb3B5cmlnaHQg KEMpIDIwMDItMyBCcnVjZSBBbGxlbiAKTWFyIDEwIDA4OjQwOjIxIGZjMm1l IHNtYXJ0ZFsxMTI0XTogSG9tZSBwYWdlIGlzIGh0dHA6Ly9zbWFydG1vbnRv b2xzLnNvdXJjZWZvcmdlLm5ldC8gIApNYXIgMTAgMDg6NDA6MjEgZmMybWUg c21hcnRkWzExMjRdOiBPcGVuZWQgY29uZmlndXJhdGlvbiBmaWxlIC9ldGMv c21hcnRkLmNvbmYgCk1hciAxMCAwODo0MDoyMSBmYzJtZSBzbWFydGRbMTEy NF06IENvbmZpZ3VyYXRpb24gZmlsZSAvZXRjL3NtYXJ0ZC5jb25mIHBhcnNl ZC4gCk1hciAxMCAwODo0MDoyMSBmYzJtZSBtb2Rwcm9iZTogV0FSTklORzog L2V0Yy9tb2Rwcm9iZS5jb25mIGxpbmUgMzogaWdub3JpbmcgYmFkIGxpbmUg c3RhcnRpbmcgd2l0aCAncG9zdC1pbnN0YWxsJyAKTWFyIDEwIDA4OjQwOjIx IGZjMm1lIG1vZHByb2JlOiBXQVJOSU5HOiAvZXRjL21vZHByb2JlLmNvbmYg bGluZSAzOiBpZ25vcmluZyBiYWQgbGluZSBzdGFydGluZyB3aXRoICdwb3N0 LWluc3RhbGwnIApNYXIgMTAgMDg6NDA6MjIgZmMybWUgc21hcnRkWzExMjRd OiBEZXZpY2U6IC9kZXYvaGRhLCBObyBzdWNoIGRldmljZSBvciBhZGRyZXNz LCBvcGVuKCkgZmFpbGVkIApNYXIgMTAgMDg6NDA6MjIgZmMybWUgc21hcnRk WzExMjRdOiBVbmFibGUgdG8gcmVnaXN0ZXIgQVRBIGRldmljZSAvZGV2L2hk YSBhdCBsaW5lIDMwIG9mIGZpbGUgL2V0Yy9zbWFydGQuY29uZiAKTWFyIDEw IDA4OjQwOjIyIGZjMm1lIHNtYXJ0ZFsxMTI0XTogVW5hYmxlIHRvIHJlZ2lz dGVyIGRldmljZSAvZGV2L2hkYSAobm8gRGlyZWN0aXZlIC1kIHJlbW92YWJs ZSkuIEV4aXRpbmcuIApNYXIgMTAgMDg6NDA6MjIgZmMybWUgc21hcnRkOiBz bWFydGQgc3RhcnR1cCBmYWlsZWQKTWFyIDEwIDA4OjQwOjIyIGZjMm1lIGFw bWRbMTA4Nl06IENoYXJnZTogKiAqICogKC0xJSB1bmtub3duKQpNYXIgMTAg MDg6NDA6MjQgZmMybWUgbW9kcHJvYmU6IFdBUk5JTkc6IC9ldGMvbW9kcHJv YmUuY29uZiBsaW5lIDM6IGlnbm9yaW5nIGJhZCBsaW5lIHN0YXJ0aW5nIHdp dGggJ3Bvc3QtaW5zdGFsbCcgCk1hciAxMCAwODo0MDoyNCBmYzJtZSBrZXJu ZWw6IGxwMDogdXNpbmcgcGFycG9ydDAgKHBvbGxpbmcpLgpNYXIgMTAgMDg6 NDA6MjQgZmMybWUga2VybmVsOiBscDA6IGNvbnNvbGUgcmVhZHkKTWFyIDEw IDA4OjQwOjI0IGZjMm1lIG1vZHByb2JlOiBXQVJOSU5HOiAvZXRjL21vZHBy b2JlLmNvbmYgbGluZSAzOiBpZ25vcmluZyBiYWQgbGluZSBzdGFydGluZyB3 aXRoICdwb3N0LWluc3RhbGwnIApNYXIgMTAgMDg6NDA6MzEgZmMybWUgbGFz dCBtZXNzYWdlIHJlcGVhdGVkIDc5IHRpbWVzCk1hciAxMCAwODo0MDozMSBm YzJtZSBjdXBzOiBjdXBzZCBzdGFydHVwIHN1Y2NlZWRlZApNYXIgMTAgMDg6 NDA6MzIgZmMybWUgc3NoZDogUlNBMSBrZXkgZ2VuZXJhdGlvbiBzdWNjZWVk ZWQKTWFyIDEwIDA4OjQwOjMzIGZjMm1lIHNzaGQ6IFJTQSBrZXkgZ2VuZXJh dGlvbiBzdWNjZWVkZWQKTWFyIDEwIDA4OjQwOjM5IGZjMm1lIHNzaGQ6IERT QSBrZXkgZ2VuZXJhdGlvbiBzdWNjZWVkZWQKTWFyIDEwIDA4OjQwOjM5IGZj Mm1lIG1vZHByb2JlOiBXQVJOSU5HOiAvZXRjL21vZHByb2JlLmNvbmYgbGlu ZSAzOiBpZ25vcmluZyBiYWQgbGluZSBzdGFydGluZyB3aXRoICdwb3N0LWlu c3RhbGwnIApNYXIgMTAgMDg6NDA6MzkgZmMybWUgbW9kcHJvYmU6IFdBUk5J Tkc6IC9ldGMvbW9kcHJvYmUuY29uZiBsaW5lIDM6IGlnbm9yaW5nIGJhZCBs aW5lIHN0YXJ0aW5nIHdpdGggJ3Bvc3QtaW5zdGFsbCcgCk1hciAxMCAwODo0 MDozOSBmYzJtZSBrZXJuZWw6IE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBm YW1pbHkgMTAKTWFyIDEwIDA4OjQwOjM5IGZjMm1lIGtlcm5lbDogRGlzYWJs ZWQgUHJpdmFjeSBFeHRlbnNpb25zIG9uIGRldmljZSBjMDM5ZDk4MChsbykK TWFyIDEwIDA4OjQwOjM5IGZjMm1lIGtlcm5lbDogSVB2NiBvdmVyIElQdjQg dHVubmVsaW5nIGRyaXZlcgpNYXIgMTAgMDg6NDA6NDAgZmMybWUgc3NoZDog IHN1Y2NlZWRlZApNYXIgMTAgMDg6NDA6NDAgZmMybWUgeGluZXRkOiB4aW5l dGQgc3RhcnR1cCBzdWNjZWVkZWQKTWFyIDEwIDA4OjQwOjQxIGZjMm1lIHNl bmRtYWlsOiBzZW5kbWFpbCBzdGFydHVwIHN1Y2NlZWRlZApNYXIgMTAgMDg6 NDA6NDIgZmMybWUgc2VuZG1haWw6IHNtLWNsaWVudCBzdGFydHVwIHN1Y2Nl ZWRlZApNYXIgMTAgMDg6NDA6NDIgZmMybWUgeGluZXRkWzEzODVdOiB4aW5l dGQgVmVyc2lvbiAyLjMuMTIgc3RhcnRlZCB3aXRoIGxpYndyYXAgbG9hZGF2 ZyBvcHRpb25zIGNvbXBpbGVkIGluLgpNYXIgMTAgMDg6NDA6NDIgZmMybWUg eGluZXRkWzEzODVdOiBTdGFydGVkIHdvcmtpbmc6IDEgYXZhaWxhYmxlIHNl cnZpY2UKTWFyIDEwIDA4OjQwOjQyIGZjMm1lIGdwbTogZ3BtIHN0YXJ0dXAg c3VjY2VlZGVkCk1hciAxMCAwODo0MDo0MyBmYzJtZSBjcm9uZDogY3JvbmQg c3RhcnR1cCBzdWNjZWVkZWQKTWFyIDEwIDA4OjQwOjQzIGZjMm1lIHhmczog eGZzIHN0YXJ0dXAgc3VjY2VlZGVkCk1hciAxMCAwODo0MDo0NCBmYzJtZSBh bmFjcm9uOiBhbmFjcm9uIHN0YXJ0dXAgc3VjY2VlZGVkCk1hciAxMCAwODo0 MDo0NCBmYzJtZSB4ZnM6IGlnbm9yaW5nIGZvbnQgcGF0aCBlbGVtZW50IC91 c3IvWDExUjYvbGliL1gxMS9mb250cy9jeXJpbGxpYyAodW5yZWFkYWJsZSkg Ck1hciAxMCAwODo0MDo0NCBmYzJtZSBhdGQ6IGF0ZCBzdGFydHVwIHN1Y2Nl ZWRlZApNYXIgMTAgMDg6NDA6NDUgZmMybWUgZ2NvbmZkIChyb290LTE0OTYp OiBzdGFydGluZyAodmVyc2lvbiAyLjUuMSksIHBpZCAxNDk2IHVzZXIgJ3Jv b3QnCk1hciAxMCAwODo0MDo0NiBmYzJtZSBnY29uZmQgKHJvb3QtMTQ5Nik6 IFJlc29sdmVkIGFkZHJlc3MgInhtbDpyZWFkb25seTovZXRjL2djb25mL2dj b25mLnhtbC5tYW5kYXRvcnkiIHRvIGEgcmVhZC1vbmx5IGNvbmZpZyBzb3Vy Y2UgYXQgcG9zaXRpb24gMApNYXIgMTAgMDg6NDA6NDYgZmMybWUgZ2NvbmZk IChyb290LTE0OTYpOiBSZXNvbHZlZCBhZGRyZXNzICJ4bWw6cmVhZHdyaXRl Oi9yb290Ly5nY29uZiIgdG8gYSB3cml0YWJsZSBjb25maWcgc291cmNlIGF0 IHBvc2l0aW9uIDEKTWFyIDEwIDA4OjQwOjQ2IGZjMm1lIGdjb25mZCAocm9v dC0xNDk2KTogUmVzb2x2ZWQgYWRkcmVzcyAieG1sOnJlYWRvbmx5Oi9ldGMv Z2NvbmYvZ2NvbmYueG1sLmRlZmF1bHRzIiB0byBhIHJlYWQtb25seSBjb25m aWcgc291cmNlIGF0IHBvc2l0aW9uIDIKTWFyIDEwIDA4OjQwOjU1IGZjMm1l IGtlcm5lbDogcHl0aG9uMjogbnVtZXJpY2FsIHN5c2N0bCAxIDIzIGlzIG9i c29sZXRlLgpNYXIgMTAgMDg6NDA6NTggZmMybWUga2VybmVsOiBkZGNwcm9i ZTogbnVtZXJpY2FsIHN5c2N0bCAxIDIzIGlzIG9ic29sZXRlLgpNYXIgMTAg MDg6NDA6NTkgZmMybWUga2VybmVsOiBweXRob24yOiBudW1lcmljYWwgc3lz Y3RsIDEgMjMgaXMgb2Jzb2xldGUuCk1hciAxMCAwODo0MTowMSBmYzJtZSBr ZXJuZWw6IGRkY3Byb2JlOiBudW1lcmljYWwgc3lzY3RsIDEgMjMgaXMgb2Jz b2xldGUuCk1hciAxMCAwODo0MTowMiBmYzJtZSBrZXJuZWw6IHB5dGhvbjI6 IG51bWVyaWNhbCBzeXNjdGwgMSAyMyBpcyBvYnNvbGV0ZS4KTWFyIDEwIDA4 OjQxOjA0IGZjMm1lIGtlcm5lbDogZGRjcHJvYmU6IG51bWVyaWNhbCBzeXNj dGwgMSAyMyBpcyBvYnNvbGV0ZS4KTWFyIDEwIDA4OjQxOjA2IGZjMm1lIGtl cm5lbDogcHl0aG9uMjogbnVtZXJpY2FsIHN5c2N0bCAxIDIzIGlzIG9ic29s ZXRlLgpNYXIgMTAgMDg6NDE6MDYgZmMybWUga2VybmVsOiBweXRob24yOiBu dW1lcmljYWwgc3lzY3RsIDEgMjMgaXMgb2Jzb2xldGUuCk1hciAxMCAwODo0 MjowMSBmYzJtZSBudHBkOiAgc3VjY2VlZGVkCk1hciAxMCAwODo0MjowMSBm YzJtZSBudHBkOiAgc3VjY2VlZGVkCk1hciAxMCAwODozNjo0NyBmYzJtZSBu dHBkYXRlWzE1NDZdOiBzdGVwIHRpbWUgc2VydmVyIDE5OC44Mi4xNjIuMjEz IG9mZnNldCAtMzEzLjYzMjI2OCBzZWMKTWFyIDEwIDA4OjM2OjQ3IGZjMm1l IG50cGQ6ICBzdWNjZWVkZWQKTWFyIDEwIDA4OjM2OjQ3IGZjMm1lIG50cGQ6 IG50cGQgc3RhcnR1cCBzdWNjZWVkZWQKTWFyIDEwIDA4OjM2OjQ3IGZjMm1l IG50cGRbMTU1MF06IG50cGQgNC4yLjBAMS4xMTYxLXIgV2VkIEphbiAyOCAw OToyMDo1MiBFU1QgMjAwNCAoMSkKTWFyIDEwIDA4OjM2OjQ4IGZjMm1lIG50 cGRbMTU1MF06IHByZWNpc2lvbiA9IDIuMDAwIHVzZWMKTWFyIDEwIDA4OjM2 OjQ4IGZjMm1lIG50cGRbMTU1MF06IGtlcm5lbCB0aW1lIHN5bmMgc3RhdHVz IDAwNDAKTWFyIDEwIDA4OjM2OjQ4IGZjMm1lIG50cGRbMTU1MF06IGZyZXF1 ZW5jeSBpbml0aWFsaXplZCAwLjAwMCBQUE0gZnJvbSAvdmFyL2xpYi9udHAv ZHJpZnQKTWFyIDEwIDA4OjM2OjQ4IGZjMm1lIG50cGRbMTU1MF06IGNvbmZp Z3VyZToga2V5d29yZCAiYXV0aGVudGljYXRlIiB1bmtub3duLCBsaW5lIGln bm9yZWQKTWFyIDEwIDA4OjM3OjM1IGZjMm1lIGZpcnN0Ym9vdDogIHN1Y2Nl ZWRlZApNYXIgMTAgMDg6Mzc6MzUgZmMybWUgcmVhZGFoZWFkOiBTdGFydGlu ZyBiYWNrZ3JvdW5kIHJlYWRhaGVhZDogCk1hciAxMCAwODozNzozNiBmYzJt ZSByYzogU3RhcnRpbmcgcmVhZGFoZWFkOiAgc3VjY2VlZGVkCk1hciAxMCAw ODozNzozNiBmYzJtZSBtZXNzYWdlYnVzOiBtZXNzYWdlYnVzIHN0YXJ0dXAg c3VjY2VlZGVkCk1hciAxMCAwODozNzozOCBmYzJtZSBpbml0OiBvcGVuKC9k ZXYvcHRzLzApOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Ck1hciAxMCAw ODozNzozOCBmYzJtZSBpbml0OiBvcGVuKC9kZXYvcHRzLzApOiBObyBzdWNo IGZpbGUgb3IgZGlyZWN0b3J5Ck1hciAxMCAwODozNzo0NCBmYzJtZSBrZXJu ZWw6IFBDSTogRm91bmQgSVJRIDEwIGZvciBkZXZpY2UgMDAwMDowMDowZS4w Ck1hciAxMCAwODozNzo0NCBmYzJtZSBrZXJuZWw6IGF0a2JkLmM6IFVua25v d24ga2V5IHJlbGVhc2VkICh0cmFuc2xhdGVkIHNldCAyLCBjb2RlIDB4N2Eg b24gaXNhMDA2MC9zZXJpbzApLgpNYXIgMTAgMDg6Mzc6NDQgZmMybWUga2Vy bmVsOiBhdGtiZC5jOiBUaGlzIGlzIGFuIFhGcmVlODYgYnVnLiBJdCBzaG91 bGRuJ3QgYWNjZXNzIGhhcmR3YXJlIGRpcmVjdGx5LgpNYXIgMTAgMDg6Mzc6 NDQgZmMybWUga2VybmVsOiBhdGtiZC5jOiBVbmtub3duIGtleSByZWxlYXNl ZCAodHJhbnNsYXRlZCBzZXQgMiwgY29kZSAweDdhIG9uIGlzYTAwNjAvc2Vy aW8wKS4KTWFyIDEwIDA4OjM3OjQ0IGZjMm1lIGtlcm5lbDogYXRrYmQuYzog VGhpcyBpcyBhbiBYRnJlZTg2IGJ1Zy4gSXQgc2hvdWxkbid0IGFjY2VzcyBo YXJkd2FyZSBkaXJlY3RseS4KTWFyIDEwIDA4OjM4OjAyIGZjMm1lIGdjb25m ZCAocm9vdC0xNDk2KTogR0NvbmYgc2VydmVyIGlzIG5vdCBpbiB1c2UsIHNo dXR0aW5nIGRvd24uCk1hciAxMCAwODozODowMiBmYzJtZSBnY29uZmQgKHJv b3QtMTQ5Nik6IEV4aXRpbmcKTWFyIDEwIDA4OjM4OjA2IGZjMm1lIGdkbShw YW1fdW5peClbMTYzOF06IHNlc3Npb24gb3BlbmVkIGZvciB1c2VyIG11cnRo eSBieSAodWlkPTApCk1hciAxMCAwODozODoxMSBmYzJtZSBnY29uZmQgKG11 cnRoeS0xNzA1KTogc3RhcnRpbmcgKHZlcnNpb24gMi41LjEpLCBwaWQgMTcw NSB1c2VyICdtdXJ0aHknCk1hciAxMCAwODozODoxMSBmYzJtZSBnY29uZmQg KG11cnRoeS0xNzA1KTogUmVzb2x2ZWQgYWRkcmVzcyAieG1sOnJlYWRvbmx5 Oi9ldGMvZ2NvbmYvZ2NvbmYueG1sLm1hbmRhdG9yeSIgdG8gYSByZWFkLW9u bHkgY29uZmlnIHNvdXJjZSBhdCBwb3NpdGlvbiAwCk1hciAxMCAwODozODox MSBmYzJtZSBnY29uZmQgKG11cnRoeS0xNzA1KTogUmVzb2x2ZWQgYWRkcmVz cyAieG1sOnJlYWR3cml0ZTovaG9tZS9tdXJ0aHkvLmdjb25mIiB0byBhIHdy aXRhYmxlIGNvbmZpZyBzb3VyY2UgYXQgcG9zaXRpb24gMQpNYXIgMTAgMDg6 Mzg6MTEgZmMybWUgZ2NvbmZkIChtdXJ0aHktMTcwNSk6IFJlc29sdmVkIGFk ZHJlc3MgInhtbDpyZWFkb25seTovZXRjL2djb25mL2djb25mLnhtbC5kZWZh dWx0cyIgdG8gYSByZWFkLW9ubHkgY29uZmlnIHNvdXJjZSBhdCBwb3NpdGlv biAyCk1hciAxMCAwODozODoxMiBmYzJtZSBib25vYm8tYWN0aXZhdGlvbi1z ZXJ2ZXIgKG11cnRoeS0xNzEwKTogaWlkIE9BRklJRDpCcm9rZW5Ob1R5cGU6 MjAwMDA4MDggaGFzIGEgTlVMTCB0eXBlCk1hciAxMCAwODozODoxMiBmYzJt ZSBib25vYm8tYWN0aXZhdGlvbi1zZXJ2ZXIgKG11cnRoeS0xNzEwKTogaW52 YWxpZCBjaGFyYWN0ZXIgJyMnIGluIGlpZCAnT0FGSUlEOlRoaXMjISElJGlp ZCVeJCVffH4hT0FGSUlEX0NvbnRhaW5zQmFkQ2hhcnMnCk1hciAxMCAwODoz ODoxNiBmYzJtZSB4aW5ldGRbMTcyMV06IHdhcm5pbmc6IGNhbid0IGdldCBj bGllbnQgYWRkcmVzczogVHJhbnNwb3J0IGVuZHBvaW50IGlzIG5vdCBjb25u ZWN0ZWQKTWFyIDEwIDA4OjM4OjE5IGZjMm1lIG1vZHByb2JlOiBXQVJOSU5H OiAvZXRjL21vZHByb2JlLmNvbmYgbGluZSAzOiBpZ25vcmluZyBiYWQgbGlu ZSBzdGFydGluZyB3aXRoICdwb3N0LWluc3RhbGwnIApNYXIgMTAgMDg6Mzg6 NDEgZmMybWUgbGFzdCBtZXNzYWdlIHJlcGVhdGVkIDggdGltZXMKTWFyIDEw IDA4OjQ1OjIzIGZjMm1lIG50cGRbMTU1MF06IHN5bmNocm9uaXplZCB0byAx OTguODIuMTYyLjIxMywgc3RyYXR1bT0yCk1hciAxMCAwODo0NToyMyBmYzJt ZSBudHBkWzE1NTBdOiBrZXJuZWwgdGltZSBzeW5jIGRpc2FibGVkIDAwNDEK TWFyIDEwIDA4OjUwOjQyIGZjMm1lIHNzaGQocGFtX3VuaXgpWzE5MjldOiBz ZXNzaW9uIG9wZW5lZCBmb3IgdXNlciBtdXJ0aHkgYnkgKHVpZD01MDApCk1h ciAxMCAwODo1MTowNCBmYzJtZSBzc2hkKHBhbV91bml4KVsxOTI5XTogc2Vz c2lvbiBjbG9zZWQgZm9yIHVzZXIgbXVydGh5Ck1hciAxMCAwOTowMDoyMyBm YzJtZSBudHBkWzE1NTBdOiBrZXJuZWwgdGltZSBzeW5jIGVuYWJsZWQgMDAw MQpNYXIgMTAgMDk6MDQ6NDMgZmMybWUgbnRwZFsxNTUwXTogbm8gc2VydmVy cyByZWFjaGFibGUKTWFyIDEwIDA5OjA1OjQ5IGZjMm1lIG50cGRbMTU1MF06 IHN5bmNocm9uaXplZCB0byAxOTguODIuMTYyLjIxMywgc3RyYXR1bT0yCk1h ciAxMCAwOTowNjo1MyBmYzJtZSBzdShwYW1fdW5peClbMjA0Ml06IHNlc3Np b24gb3BlbmVkIGZvciB1c2VyIHJvb3QgYnkgbXVydGh5KHVpZD01MDApCg== ------_=_NextPart_001_01C406BD.9D1D19AC-- From owner-linux-xfs@oss.sgi.com Wed Mar 10 08:54:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 08:54:07 -0800 (PST) Received: from mx.leogic.com (mx.leogic.com [62.245.182.8]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2AGrxKO028933 for ; Wed, 10 Mar 2004 08:54:00 -0800 Received: from leogic.com ([192.168.41.28]) (authenticated bits=0) by mx.leogic.com (8.12.11/8.12.10) with ESMTP id i2AGtinr024861 (version=TLSv1/SSLv3 cipher=IDEA-CBC-SHA bits=128 verify=NO); Wed, 10 Mar 2004 17:55:45 +0100 Message-ID: <404F481C.5090801@leogic.com> Date: Wed, 10 Mar 2004 17:53:48 +0100 From: "Errikos Pitsos {secure}" Organization: leogic User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040126 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Eric Sandeen {unsecure}" CC: "linux-xfs@oss.sgi.com {unsecure}" Subject: Re: ran into rare bug: "unable to verify superblock, continuing..." References: <404ED170.9000601@leogic.com> <1078936989.18173.13.camel@stout.americas.sgi.com> In-Reply-To: <1078936989.18173.13.camel@stout.americas.sgi.com> X-Enigmail-Version: 0.83.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2405 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ep@leogic.com Precedence: bulk X-list: linux-xfs Content-Length: 46918 Lines: 951 the machine has three partitions. 1 boot 2 swap 3 root it's a laptop hd. I took it out of the one laptop and put it into another because I wanted to transfer 50gb onto it and because I wanted to change partition 2 and 3. So resized 2 and 3, which naturally deleted the data on both of them. Mounted part3 and copied 50gb of data onto it. Then I shutdown the machine(where I didn't find a syslog entry for the xfs part being properly unmounted, don't know whether this is normally always logged) and put the hd back into the original laptop. She booted fine, grub, everything, but during kernel loading isn't able to mount the xfs. partition(root) I took the hd out again and tried mounting the hd on the system where I had copied the stuff from. Nothing works there either, so that's where I am now. e Eric Sandeen {u} wrote: > Any chance you put your bootloader on the root partition, rather than > the mbr? XFS uses block zero, as would the bootloader if you put it > there. > > Still, not sure offhand why repair did not fix things up. > > On Wed, 2004-03-10 at 02:27, Errikos Pitsos {secure} wrote: > >>Hi! >> >>Seems like I ran into a known problem wrt to "unable to verify >>superblock, continuing..." >>http://oss.sgi.com/projects/xfs/faq.html#xfsmountfail >> >>I can't mount the xfs fs. >>I can't repair the xfs fs. >>Yes, this is my root partition, this is a new system I was setting up. >>I don't know what caused the trouble, but it seems that somehow the >>system was not properly unmounted. >>Using xfs_repai without "L" doesn't change anything. >>So if I can help finding that bug tell me. >>I am using Gentoo and had a 2.4.24-xfs-r3 on there, syslog says: >>Mar 10 07:56:43 leonzwei SGI XFS snapshot-2.4.23-2003-12-01_00:33_UTC >>with no debug enabled >> >>For some reason it seems that the XFS was not cleanly unmounted, not >>sure though. The system was cleanly shutdown, but I didn't find a: >> Mar 10 03:47:25 leonzwei Ending clean XFS mount for filesystem: ide1(22,3) >> >>in there which I had before. >> >> >>syslog shows these here when I try to mount the partition. >>Mar 10 08:03:37 leonzwei XFS: bad magic number >>Mar 10 08:03:37 leonzwei XFS: SB validate failed >> >> >> >>here some console output: >> >>leonzwei root # xfs_repair -nLv /dev/hdc3 >>Phase 1 - find and verify superblock... >>bad primary superblock - bad magic number !!! >> >>attempting to find secondary superblock... >>........................................................................................................... >> >> >>.....................found candidate secondary superblock... >>error reading superblock 54 -- seek to offset 57982058496 failed >>unable to verify superblock, continuing... >>........................................................................................................... >> >> >>........................................................................................................... >> >> >>........................................................................................................... >> >> >>........................................................................................................... >> >> >>........................................................................................................... >> >> >>........................................................................................................... >> >> >>........................................................................................................... >> >> >>........................................................................................................... >> >> >>........................................................................................................... >> >> >>.............................................................found >>candidate secondary superblock... >>error reading superblock 54 -- seek to offset 57982058496 failed >>unable to verify superblock, continuing... >>........................................................................................................... >> >> >>........................................................................................................... >> >> >>........................................................................................................... >> >> >>........................................................................................................... >> >> >>........................................................................................................... >> >> >>........................................................................................................... >> >> >>........................................................................................................... >> >> >>........................................................................................................... >> >> >>........................................................................................................... >> >> >>.............................................................found >>candidate secondary superblock... >>error reading superblock 54 -- seek to offset 57982058496 failed >>unable to verify superblock, continuing... >> >> >>goes on for ever. >> >>here something else that I saw that you requested from somebody who had >>the same bug: >> >>leonzwei root # xfs_db /dev/hdc3 >>xfs_db: unexpected XFS SB magic number 0x1917d8b3 >>xfs_db: sb 0 >>xfs_db: p >>magicnum = 0x1917d8b3 >>blocksize = 689553475 >>dblocks = 12180848741608851668 >>rblocks = 8457844901802481315 >>rextents = 17089333805017595916 >>uuid = c005688d-587d-e4b5-7729-c2cd4e81e350 >>logstart = 12437974581420056107 >>rootino = 2035592538136216092 >>rbmino = 2311019282328682982 >>rsumino = 940638864488651459 >>rextsize = 4062341194 >>agblocks = 1795335310 >>agcount = 3583083788 >>rbmblocks = 745776455 >>logblocks = 2344638215 >>versionnum = 0xcd77 >>sectsize = 57419 >>inodesize = 22122 >>inopblock = 22912 >>fname = "q\275\347\017o;\202\376>blocklog = 253 >>sectlog = 155 >>inodelog = 111 >>inopblog = 173 >>agblklog = 91 >>rextslog = 155 >>inprogress = 45 >>imax_pct = 183 >>icount = 3536497887666359542 >>ifree = 15647017454152257949 >>fdblocks = 15766340045555572059 >>frextents = 7127039695291382717 >>uquotino = 7880036713507589276 >>gquotino = 3559299706880429710 >>qflags = 0x5d07 >>flags = 0xe9 >>shared_vn = 152 >>inoalignmt = 237542219 >>unit = 2706140452 >>width = 574901660 >>dirblklog = 54 >>logsectlog = 60 >>logsectsize = 49029 >>logsunit = 1105637059 >>xfs_db: >> >> >>anything else I can provide bug hunters with? >> >>erik rom owner-linux-xfs@oss.sgi.com Wed Mar 10 08:59:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 08:59:58 -0800 (PST) Received: from io.goeci.com (thor.goeci.com [66.28.220.99] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2AGxdKO029756 for ; Wed, 10 Mar 2004 08:59:40 -0800 Subject: RE: fedora core2-test1 & XFS MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C406BC.F2B6A424" Date: Wed, 10 Mar 2004 11:30:06 -0500 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: <3554BFA5FAE4B14FB5459D36E4F4E36203D90C@io.goeci.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: fedora core2-test1 & XFS Thread-Index: AcQFimgMYwq53b0JQ/Cefw1rP0VfMgBK/vEA From: "Murthy Kambhampaty" To: "Eric Sandeen" , "Net Llama!" Cc: X-archive-position: 2406 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: murthy.kambhampaty@goeci.com Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. ------_=_NextPart_001_01C406BC.F2B6A424 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Installed FC2 test 1 on an old Dell box, with grub. Following are some ob= servations: 1. During "Installing bootloader ..." a. Switch to tty2 b. chown /mnt/sysimage c. /sbin/grun-install d. exit, switch to tty7 which is waiting with the "make boot disk?" dialog= (but seem below for more to do in tty2) (the rest were done from linux rescue, after the rebboot failed. You proba= bly could do them in tty2 along with step 1.) 2. Replace partition labels in /etc/grub.conf and /etc/fstab with device no= des (e.g., "LABEL=3D/" with "/dev/sda2") 3. Manually copy over xfs userspace tools from /mnt/runtime/sbin (xfs.mkfs)= and /mnt/runtime/usr/sbin (still get "missing fsck.xfs", but since XFS' mo= tto is "no more fscking boot delays" (I paraphrase), I ignore the error for= now. Needs some rc.sysinit work. 4. (This may have to be done from linux rescue, though you should be able t= o ftp or nfs over from tty2 during install) a. Copy devmap_mknod.sh from device-mapper package to /etc/init.d, chmod a= +x it b. add "post-install dm-mod /etc/init.d/devmap_mknod.sh" to /etc/modprobe.= conf (this gives an error, but isn't holding up things; the instructions fr= om device-mapper INSTALL were for old modutils and /etc/modueles.conf, need= s to be rejiggered for new ones and /etc/modprobe.conf) c. Replace LMV2 initialization with (I copied rc.sysinit to rc.sysinit.ana= conda0, and delelted the LVM initialization sections in rc.sysinit): dmsetup mknod modprobe dm-mod=20 # /etc/init.d/devmap_mknod.sh could be added here, especially if you reco= mpile dm into the kernel /sbin/lvm vgchange -ay 5. Reboot success. Probably a good idea to download latest xfs userspace r= pms and install. Sweetness ... there are still a few errors during startup (automount, smart= d), but the system is operational to my needs and is really snappy compared= to previous distros. The other big surpise was XFree86 config without has= sles on this "weird" setup: I've attached a copy of the boot log. Notably, the box is a Dell Optiplex = GXa has an integrated AGP 1x graphics controller (by nvidia) that can't be = disabled; I upgraded with an ATI Radeon 7000 (PCI). While xfree86 --config= ure worked in the past, Xconfigurator did not so it was somewhat exiting to= install RedHat 8.0 and gentoo 1.4. FC2's "firstboot" script had no proble= m with it (probably becuase it doesn't use Xconfigurator anymore, so I susp= ect this is all credit to XFree86 4.3.0, but still ...) I'll hunt down the FC2 support address to which to send this, but thought I= 'd preview here since there were some inquiries lately about FC2 on this li= st. More on hardware: Dell OptilPlex Gxa, jumpered for 300MHz CPU clock Pentium III 600 MHz (Coppermine goodness), running at 300 MHz 384 MB RAM Adaptec 29160 U160 controller Fujitsu 18 GB SCSI HDD 3x Compaq SCSI2 HDD Dell LS1528 monitor configured as VS14/15 More on disk/partition layout: grub on /dev/sda /dev/sda has 4 primary partitions as follows: root on /dev/sda2 (xfs) boot on /dev/sda1 (xfs) swap on /dev/sda3 (2xRAM) VGsys on /dev/sda4 /dev/VGsys/LVusr /dev/VGsys/LVvar /dev/VGsys/LVtmp /dev/VGsys/LVopt /dev/VGsys/LVhome /dev/md0 is RAID0 over /dev/sdc1 and /dev/sdd1; /dev/md0 is in /dev/VGdata,= meant for playing around with > -----Original Message----- > From: linux-xfs-bounce@oss.sgi.com > [mailto:linux-xfs-bounce@oss.sgi.com]On Behalf Of Eric Sandeen > Sent: Monday, March 08, 2004 10:55 PM > To: Net Llama! > Cc: linux-xfs@oss.sgi.com > Subject: Re: fedora core2-test1 & XFS >=20 >=20 > Thanks for the feedback - I did not quite expect grub > to work. It seems to want to access the bits on disk > via the filesystem and via the block device, almost at the > same time. This often does not work, because things > are not coherent between the two. >=20 > If you have the time, please file bugs with Red Hat on the xfs > integration problems you find - xfs is not explicitly supported=20 > (well... nothing in Fedora is supported...) but it'd be nice > to get these on-record. >=20 > Thanks! >=20 > -Eric >=20 > On Mon, 8 Mar 2004, Net Llama! wrote: >=20 > > Funny you should ask. The installer hung when it got to=20 > the point of=20 > > installing Grub. There doesn't seem to be any choice in=20 > bootloaders,=20 > > its Grub or, you're on your own. I guess i could have=20 > hacked LILO into=20 > > place post-install, but i really wasn't in the mood for=20 > such heroics.=20 > > I'm still a die-hard LILO fan, and this grub stuff just rubs me the=20 > > wrong way, even if it went swimmingly. > >=20 > > At any rate, i followed this advice: > > http://marc.theaimsgroup.com/?l=3Dlinux-xfs&m=3D107704299608539&w=3D2 > >=20 > > and it appeared to get me back in business. Or so I thought, but=20 > > apparently killing grub manually sends anaconda into a tila=20 > spin, and=20 > > the installer self-terminates abnormally. > >=20 > > Looks like Redhat still hasn't quite figured out this XFS=20 > concept. Upon=20 > > boot it tries to run fsck.xfs which doesn't exist. That=20 > seemed to freak=20 > > out the boot process a bit. At any rate, i've got a 2.6.1=20 > kernel to=20 > > play with, so i'm moderately satisfied. > >=20 > > You SGI folks are miles ahead of Redhat on getting their distro to=20 > > install properly. > >=20 > > On 03/08/04 16:32, Eric Sandeen wrote: > >=20 > > > Out of curiosity, did you use the grub bootloader? > > >=20 > > > -Eric > > >=20 > > > On Mon, 8 Mar 2004, Net Llama! wrote: > > >=20 > > >=20 > > >>Yup that worked perfectly. thanks! > > >> > > >>On 03/05/04 20:29, Eric Sandeen wrote: > > >> > > >> > > >>>I believe it does, as an unsupported option - try > > >>>booting "linux xfs" at the prompt, or something like that. > > >>> > > >>>And let us know how it goes. :) > > >>> > > >>>-eric > > >>> > >=20 > >=20 > > --=20 > >=20 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > L. Friedman netllama@linux-sxs.org > > Linux Step-by-step & TyGeMo:=20=09=09=20=20=20=20 http://netllama.ipfox.com >=20 > 19:35:01 up 93 days, 14 min, 1 user, load average: 0.14, 0.20, 0.18 >=20 ------_=_NextPart_001_01C406BC.F2B6A424 Content-Type: application/octet-stream; name="fc2me.messages" Content-Transfer-Encoding: base64 Content-Description: fc2me.messages Content-Disposition: attachment; filename="fc2me.messages" TWFyIDEwIDA4OjQwOjE3IGZjMm1lIHN5c2xvZ2QgMS40LjE6IHJlc3RhcnQu Ck1hciAxMCAwODo0MDoxNyBmYzJtZSBzeXNsb2c6IHN5c2xvZ2Qgc3RhcnR1 cCBzdWNjZWVkZWQKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDoga2xv Z2QgMS40LjEsIGxvZyBzb3VyY2UgPSAvcHJvYy9rbXNnIHN0YXJ0ZWQuCk1h ciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IExpbnV4IHZlcnNpb24gMi42 LjEtMS42NSAoYmhjb21waWxlQHBvcmt5LmRldmVsLnJlZGhhdC5jb20pIChn Y2MgdmVyc2lvbiAzLjMuMiAyMDA0MDExOSAoUmVkIEhhdCBMaW51eCAzLjMu Mi04KSkgIzEgRnJpIEphbiAzMCAxNzoyODo1NCBFU1QgMjAwNApNYXIgMTAg MDg6NDA6MTggZmMybWUga2VybmVsOiBCSU9TLXByb3ZpZGVkIHBoeXNpY2Fs IFJBTSBtYXA6Ck1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6ICBCSU9T LWU4MjA6IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMGEwMDAwICh1 c2FibGUpCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6ICBCSU9TLWU4 MjA6IDAwMDAwMDAwMDAwZjAwMDAgLSAwMDAwMDAwMDAwMTAwMDAwIChyZXNl cnZlZCkKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogIEJJT1MtZTgy MDogMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwMTdmZmUwMDAgKHVzYWJs ZSkKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogIEJJT1MtZTgyMDog MDAwMDAwMDAxN2ZmZTAwMCAtIDAwMDAwMDAwMTgwMDAwMDAgKHJlc2VydmVk KQpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiAgQklPUy1lODIwOiAw MDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQp Ck1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IDBNQiBISUdITUVNIGF2 YWlsYWJsZS4KTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogMzgzTUIg TE9XTUVNIGF2YWlsYWJsZS4KTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5l bDogT24gbm9kZSAwIHRvdGFscGFnZXM6IDk4MzAyCk1hciAxMCAwODo0MDox OCBmYzJtZSBrZXJuZWw6ICAgRE1BIHpvbmU6IDQwOTYgcGFnZXMsIExJRk8g YmF0Y2g6MQpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiAgIE5vcm1h bCB6b25lOiA5NDIwNiBwYWdlcywgTElGTyBiYXRjaDoxNgpNYXIgMTAgMDg6 NDA6MTggZmMybWUga2VybmVsOiAgIEhpZ2hNZW0gem9uZTogMCBwYWdlcywg TElGTyBiYXRjaDoxCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IERN SSAyLjIgcHJlc2VudC4KTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDog QUNQSSBkaXNhYmxlZCBiZWNhdXNlIHlvdXIgYmlvcyBpcyBmcm9tIDAwIGFu ZCB0b28gb2xkCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IFlvdSBj YW4gZW5hYmxlIGl0IHdpdGggYWNwaT1mb3JjZQpNYXIgMTAgMDg6NDA6MTgg ZmMybWUgc3lzbG9nOiBrbG9nZCBzdGFydHVwIHN1Y2NlZWRlZApNYXIgMTAg MDg6NDA6MTggZmMybWUga2VybmVsOiBCdWlsZGluZyB6b25lbGlzdCBmb3Ig bm9kZSA6IDAKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogS2VybmVs IGNvbW1hbmQgbGluZTogcm8gcm9vdD0vZGV2L3NkYTIgcmhnYgpNYXIgMTAg MDg6NDA6MTggZmMybWUga2VybmVsOiBJbml0aWFsaXppbmcgQ1BVIzAKTWFy IDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogUElEIGhhc2ggdGFibGUgZW50 cmllczogMjA0OCAob3JkZXIgMTE6IDE2Mzg0IGJ5dGVzKQpNYXIgMTAgMDg6 NDA6MTggZmMybWUga2VybmVsOiBEZXRlY3RlZCAyOTcuOTk5IE1IeiBwcm9j ZXNzb3IuCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IFVzaW5nIHRz YyBmb3IgaGlnaC1yZXMgdGltZXNvdXJjZQpNYXIgMTAgMDg6NDA6MTggZmMy bWUga2VybmVsOiBDb25zb2xlOiBjb2xvdXIgVkdBKyA4MHgyNQpNYXIgMTAg MDg6NDA6MTggZmMybWUga2VybmVsOiBNZW1vcnk6IDM4NDUzNmsvMzkzMjA4 ayBhdmFpbGFibGUgKDIxNjZrIGtlcm5lbCBjb2RlLCA3OTQwayByZXNlcnZl ZCwgNzM0ayBkYXRhLCAyNDRrIGluaXQsIDBrIGhpZ2htZW0pCk1hciAxMCAw ODo0MDoxOCBmYzJtZSBrZXJuZWw6IENoZWNraW5nIGlmIHRoaXMgcHJvY2Vz c29yIGhvbm91cnMgdGhlIFdQIGJpdCBldmVuIGluIHN1cGVydmlzb3IgbW9k ZS4uLiBPay4KTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogQ2FsaWJy YXRpbmcgZGVsYXkgbG9vcC4uLiA1ODcuNzcgQm9nb01JUFMKTWFyIDEwIDA4 OjQwOjE4IGZjMm1lIGtlcm5lbDogU2VjdXJpdHkgU2NhZmZvbGQgdjEuMC4w IGluaXRpYWxpemVkCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IFNF TGludXg6ICBJbml0aWFsaXppbmcuCk1hciAxMCAwODo0MDoxOCBmYzJtZSBr ZXJuZWw6IFNFTGludXg6ICBTdGFydGluZyBpbiBwZXJtaXNzaXZlIG1vZGUK TWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogVGhlcmUgaXMgYWxyZWFk eSBhIHNlY3VyaXR5IGZyYW1ld29yayBpbml0aWFsaXplZCwgcmVnaXN0ZXJf c2VjdXJpdHkgZmFpbGVkLgpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVs OiBGYWlsdXJlIHJlZ2lzdGVyaW5nIGNhcGFiaWxpdGllcyB3aXRoIHRoZSBr ZXJuZWwKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogc2VsaW51eF9y ZWdpc3Rlcl9zZWN1cml0eTogIFJlZ2lzdGVyaW5nIHNlY29uZGFyeSBtb2R1 bGUgY2FwYWJpbGl0eQpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBD YXBhYmlsaXR5IExTTSBpbml0aWFsaXplZApNYXIgMTAgMDg6NDA6MTggZmMy bWUga2VybmVsOiBEZW50cnkgY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA2 NTUzNiAob3JkZXI6IDYsIDI2MjE0NCBieXRlcykKTWFyIDEwIDA4OjQwOjE4 IGZjMm1lIGtlcm5lbDogSW5vZGUtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVz OiAzMjc2OCAob3JkZXI6IDUsIDEzMTA3MiBieXRlcykKTWFyIDEwIDA4OjQw OjE4IGZjMm1lIGtlcm5lbDogTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRy aWVzOiA1MTIgKG9yZGVyOiAwLCA0MDk2IGJ5dGVzKQpNYXIgMTAgMDg6NDA6 MTggZmMybWUga2VybmVsOiBjaGVja2luZyBpZiBpbWFnZSBpcyBpbml0cmFt ZnMuLi5pdCBpc24ndCAobm8gY3BpbyBtYWdpYyk7IGxvb2tzIGxpa2UgYW4g aW5pdHJkCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IEZyZWVpbmcg aW5pdHJkIG1lbW9yeTogNTczayBmcmVlZApNYXIgMTAgMDg6NDA6MTggZmMy bWUga2VybmVsOiBDUFU6IEwxIEkgY2FjaGU6IDE2SywgTDEgRCBjYWNoZTog MTZLCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IENQVTogTDIgY2Fj aGU6IDI1NksKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogQ1BVIHNl cmlhbCBudW1iZXIgZGlzYWJsZWQuCk1hciAxMCAwODo0MDoxOCBmYzJtZSBr ZXJuZWw6IEludGVsIG1hY2hpbmUgY2hlY2sgYXJjaGl0ZWN0dXJlIHN1cHBv cnRlZC4KTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogSW50ZWwgbWFj aGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxlZCBvbiBDUFUjMC4KTWFyIDEw IDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogQ1BVOiBJbnRlbCBQZW50aXVtIElJ SSAoQ29wcGVybWluZSkgc3RlcHBpbmcgMDMKTWFyIDEwIDA4OjQwOjE4IGZj Mm1lIGtlcm5lbDogRW5hYmxpbmcgZmFzdCBGUFUgc2F2ZSBhbmQgcmVzdG9y ZS4uLiBkb25lLgpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBFbmFi bGluZyB1bm1hc2tlZCBTSU1EIEZQVSBleGNlcHRpb24gc3VwcG9ydC4uLiBk b25lLgpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBDaGVja2luZyAn aGx0JyBpbnN0cnVjdGlvbi4uLiBPSy4KTWFyIDEwIDA4OjQwOjE4IGZjMm1l IGtlcm5lbDogUE9TSVggY29uZm9ybWFuY2UgdGVzdGluZyBieSBVTklGSVgK TWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogTkVUOiBSZWdpc3RlcmVk IHByb3RvY29sIGZhbWlseSAxNgpNYXIgMTAgMDg6NDA6MTggZmMybWUga2Vy bmVsOiBFSVNBIGJ1cyByZWdpc3RlcmVkCk1hciAxMCAwODo0MDoxOCBmYzJt ZSBrZXJuZWw6IFBDSTogUENJIEJJT1MgcmV2aXNpb24gMi4xMCBlbnRyeSBh dCAweGZjZjRlLCBsYXN0IGJ1cz0yCk1hciAxMCAwODo0MDoxOCBmYzJtZSBr ZXJuZWw6IFBDSTogVXNpbmcgY29uZmlndXJhdGlvbiB0eXBlIDEKTWFyIDEw IDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogbXRycjogdjIuMCAoMjAwMjA1MTkp Ck1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IEFDUEk6IFN1YnN5c3Rl bSByZXZpc2lvbiAyMDA0MDExNgpNYXIgMTAgMDg6NDA6MTggZmMybWUga2Vy bmVsOiBBQ1BJOiBJbnRlcnByZXRlciBkaXNhYmxlZC4KTWFyIDEwIDA4OjQw OjE4IGZjMm1lIGtlcm5lbDogTGludXggUGx1ZyBhbmQgUGxheSBTdXBwb3J0 IHYwLjk3IChjKSBBZGFtIEJlbGF5Ck1hciAxMCAwODo0MDoxOCBmYzJtZSBr ZXJuZWw6IEFDUEk6IEFDUEkgdGFibGVzIGNvbnRhaW4gbm8gUENJIElSUSBy b3V0aW5nIGVudHJpZXMKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDog UENJOiBJbnZhbGlkIEFDUEktUENJIElSUSByb3V0aW5nIHRhYmxlCk1hciAx MCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IFBDSTogUHJvYmluZyBQQ0kgaGFy ZHdhcmUKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogUENJOiBQcm9i aW5nIFBDSSBoYXJkd2FyZSAoYnVzIDAwKQpNYXIgMTAgMDg6NDA6MTggZmMy bWUga2VybmVsOiBQQ0k6IFVzaW5nIElSUSByb3V0ZXIgUElJWC9JQ0ggWzgw ODYvNzExMF0gYXQgMDAwMDowMDowNy4wCk1hciAxMCAwODo0MDoxOCBmYzJt ZSBrZXJuZWw6IE1hY2hpbmUgY2hlY2sgZXhjZXB0aW9uIHBvbGxpbmcgdGlt ZXIgc3RhcnRlZC4KTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogYXBt OiBCSU9TIHZlcnNpb24gMS4yIEZsYWdzIDB4MDMgKERyaXZlciB2ZXJzaW9u IDEuMTZhYykKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogVG90YWwg SHVnZVRMQiBtZW1vcnkgYWxsb2NhdGVkLCAwCk1hciAxMCAwODo0MDoxOCBm YzJtZSBrZXJuZWw6IFZGUzogRGlzayBxdW90YXMgZHF1b3RfNi41LjEKTWFy IDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogU0VMaW51eDogIFJlZ2lzdGVy aW5nIG5ldGZpbHRlciBob29rcwpNYXIgMTAgMDg6NDA6MTggZmMybWUga2Vy bmVsOiBJbml0aWFsaXppbmcgQ3J5cHRvZ3JhcGhpYyBBUEkKTWFyIDEwIDA4 OjQwOjE4IGZjMm1lIGtlcm5lbDogTGltaXRpbmcgZGlyZWN0IFBDSS9QQ0kg dHJhbnNmZXJzLgpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBwY2lf aG90cGx1ZzogUENJIEhvdCBQbHVnIFBDSSBDb3JlIHZlcnNpb246IDAuNQpN YXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBpc2FwbnA6IFNjYW5uaW5n IGZvciBQblAgY2FyZHMuLi4KTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5l bDogaXNhcG5wOiBDYXJkICdDUzQyMzZCJwpNYXIgMTAgMDg6NDA6MTggZmMy bWUga2VybmVsOiBpc2FwbnA6IDEgUGx1ZyAmIFBsYXkgY2FyZCBkZXRlY3Rl ZCB0b3RhbApNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBwdHk6IDIw NDggVW5peDk4IHB0eXMgY29uZmlndXJlZApNYXIgMTAgMDg6NDA6MTggZmMy bWUga2VybmVsOiBSZWFsIFRpbWUgQ2xvY2sgRHJpdmVyIHYxLjEyCk1hciAx MCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IExpbnV4IGFncGdhcnQgaW50ZXJm YWNlIHYwLjEwMCAoYykgRGF2ZSBKb25lcwpNYXIgMTAgMDg6NDA6MTggZmMy bWUga2VybmVsOiBhZ3BnYXJ0OiBEZXRlY3RlZCBhbiBJbnRlbCA0NDBMWCBD aGlwc2V0LgpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBhZ3BnYXJ0 OiBNYXhpbXVtIG1haW4gbWVtb3J5IHRvIHVzZSBmb3IgYWdwIG1lbW9yeTog MzIxTQpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBhZ3BnYXJ0OiBB R1AgYXBlcnR1cmUgaXMgNjRNIEAgMHhmMDAwMDAwMApNYXIgMTAgMDg6NDA6 MTggZmMybWUga2VybmVsOiBTZXJpYWw6IDgyNTAvMTY1NTAgZHJpdmVyICRS ZXZpc2lvbjogMS45MCAkIDggcG9ydHMsIElSUSBzaGFyaW5nIGVuYWJsZWQK TWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogdHR5UzAgYXQgSS9PIDB4 M2Y4IChpcnEgPSA0KSBpcyBhIDE2NTUwQQpNYXIgMTAgMDg6NDA6MTggZmMy bWUga2VybmVsOiB0dHlTMSBhdCBJL08gMHgyZjggKGlycSA9IDMpIGlzIGEg MTY1NTBBCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IFJBTURJU0sg ZHJpdmVyIGluaXRpYWxpemVkOiAxNiBSQU0gZGlza3Mgb2YgODE5Mksgc2l6 ZSAxMDI0IGJsb2Nrc2l6ZQpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVs OiBVbmlmb3JtIE11bHRpLVBsYXRmb3JtIEUtSURFIGRyaXZlciBSZXZpc2lv bjogNy4wMGFscGhhMgpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBp ZGU6IEFzc3VtaW5nIDMzTUh6IHN5c3RlbSBidXMgc3BlZWQgZm9yIFBJTyBt b2Rlczsgb3ZlcnJpZGUgd2l0aCBpZGVidXM9eHgKTWFyIDEwIDA4OjQwOjE4 IGZjMm1lIGtlcm5lbDogUElJWDQ6IElERSBjb250cm9sbGVyIGF0IFBDSSBz bG90IDAwMDA6MDA6MDcuMQpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVs OiBQSUlYNDogY2hpcHNldCByZXZpc2lvbiAxCk1hciAxMCAwODo0MDoxOCBm YzJtZSBrZXJuZWw6IFBJSVg0OiBub3QgMTAwJSUgbmF0aXZlIG1vZGU6IHdp bGwgcHJvYmUgaXJxcyBsYXRlcgpNYXIgMTAgMDg6NDA6MTggZmMybWUga2Vy bmVsOiAgICAgaWRlMTogQk0tRE1BIGF0IDB4ZmZhOC0weGZmYWYsIEJJT1Mg c2V0dGluZ3M6IGhkYzpETUEsIGhkZDpwaW8KTWFyIDEwIDA4OjQwOjE4IGZj Mm1lIGtlcm5lbDogaGRjOiBUT1NISUJBIENELVJPTSBYTS02MjAyQiwgQVRB UEkgQ0QvRFZELVJPTSBkcml2ZQpNYXIgMTAgMDg6NDA6MTggZmMybWUga2Vy bmVsOiBVc2luZyBhbnRpY2lwYXRvcnkgaW8gc2NoZWR1bGVyCk1hciAxMCAw ODo0MDoxOCBmYzJtZSBrZXJuZWw6IGlkZTEgYXQgMHgxNzAtMHgxNzcsMHgz NzYgb24gaXJxIDE1Ck1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IGlk ZS1mbG9wcHkgZHJpdmVyIDAuOTkubmV3aWRlCk1hciAxMCAwODo0MDoxOCBm YzJtZSBrZXJuZWw6IG1pY2U6IFBTLzIgbW91c2UgZGV2aWNlIGNvbW1vbiBm b3IgYWxsIG1pY2UKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogc2Vy aW86IGk4MDQyIEFVWCBwb3J0IGF0IDB4NjAsMHg2NCBpcnEgMTIKTWFyIDEw IDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogaW5wdXQ6IFBTLzIgR2VuZXJpYyBN b3VzZSBvbiBpc2EwMDYwL3NlcmlvMQpNYXIgMTAgMDg6NDA6MTggZmMybWUg a2VybmVsOiBzZXJpbzogaTgwNDIgS0JEIHBvcnQgYXQgMHg2MCwweDY0IGly cSAxCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IGlucHV0OiBBVCBU cmFuc2xhdGVkIFNldCAyIGtleWJvYXJkIG9uIGlzYTAwNjAvc2VyaW8wCk1h ciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IG1kOiBtZCBkcml2ZXIgMC45 MC4wIE1BWF9NRF9ERVZTPTI1NiwgTURfU0JfRElTS1M9MjcKTWFyIDEwIDA4 OjQwOjE4IGZjMm1lIGtlcm5lbDogTkVUOiBSZWdpc3RlcmVkIHByb3RvY29s IGZhbWlseSAyCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IElQOiBy b3V0aW5nIGNhY2hlIGhhc2ggdGFibGUgb2YgMTAyNCBidWNrZXRzLCAzMkti eXRlcwpNYXIgMTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBUQ1A6IEhhc2gg dGFibGVzIGNvbmZpZ3VyZWQgKGVzdGFibGlzaGVkIDMyNzY4IGJpbmQgOTM2 MikKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogSW5pdGlhbGl6aW5n IElQc2VjIG5ldGxpbmsgc29ja2V0Ck1hciAxMCAwODo0MDoxOCBmYzJtZSBr ZXJuZWw6IE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMQpNYXIg MTAgMDg6NDA6MTggZmMybWUga2VybmVsOiBORVQ6IFJlZ2lzdGVyZWQgcHJv dG9jb2wgZmFtaWx5IDE3Ck1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6 IG1kOiBBdXRvZGV0ZWN0aW5nIFJBSUQgYXJyYXlzLgpNYXIgMTAgMDg6NDA6 MTggZmMybWUga2VybmVsOiBtZDogYXV0b3J1biAuLi4KTWFyIDEwIDA4OjQw OjE4IGZjMm1lIGtlcm5lbDogbWQ6IC4uLiBhdXRvcnVuIERPTkUuCk1hciAx MCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IFJBTURJU0s6IENvbXByZXNzZWQg aW1hZ2UgZm91bmQgYXQgYmxvY2sgMApNYXIgMTAgMDg6NDA6MTggZmMybWUg a2VybmVsOiBWRlM6IE1vdW50ZWQgcm9vdCAoZXh0MiBmaWxlc3lzdGVtKS4K TWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogU0NTSSBzdWJzeXN0ZW0g aW5pdGlhbGl6ZWQKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogUENJ OiBGb3VuZCBJUlEgMTEgZm9yIGRldmljZSAwMDAwOjAyOjBhLjAKTWFyIDEw IDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogUENJOiBTaGFyaW5nIElSUSAxMSB3 aXRoIDAwMDA6MDA6MDcuMgpNYXIgMTAgMDg6NDA6MTggZmMybWUgaXJxYmFs YW5jZTogaXJxYmFsYW5jZSBzdGFydHVwIHN1Y2NlZWRlZApNYXIgMTAgMDg6 NDA6MTggZmMybWUga2VybmVsOiBQQ0k6IFNoYXJpbmcgSVJRIDExIHdpdGgg MDAwMDowMDoxMS4wCk1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IHNj c2kwIDogQWRhcHRlYyBBSUM3WFhYIEVJU0EvVkxCL1BDSSBTQ1NJIEhCQSBE UklWRVIsIFJldiA2LjIuMzYKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5l bDogICAgICAgICA8QWRhcHRlYyAyOTE2MCBVbHRyYTE2MCBTQ1NJIGFkYXB0 ZXI+Ck1hciAxMCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6ICAgICAgICAgYWlj Nzg5MjogVWx0cmExNjAgV2lkZSBDaGFubmVsIEEsIFNDU0kgSWQ9NywgMzIv MjUzIFNDQnMKTWFyIDEwIDA4OjQwOjE4IGZjMm1lIGtlcm5lbDogCk1hciAx MCAwODo0MDoxOCBmYzJtZSBrZXJuZWw6IChzY3NpMDpBOjApOiAxNjAuMDAw TUIvcyB0cmFuc2ZlcnMgKDgwLjAwME1IeiBEVCwgb2Zmc2V0IDEyNywgMTZi aXQpCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IChzY3NpMDpBOjIp OiAxMC4wMDBNQi9zIHRyYW5zZmVycyAoMTAuMDAwTUh6LCBvZmZzZXQgMTUp Ck1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IChzY3NpMDpBOjQpOiAx MC4wMDBNQi9zIHRyYW5zZmVycyAoMTAuMDAwTUh6LCBvZmZzZXQgMTUpCk1h ciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IChzY3NpMDpBOjUpOiAxMC4w MDBNQi9zIHRyYW5zZmVycyAoMTAuMDAwTUh6LCBvZmZzZXQgMTUpCk1hciAx MCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6ICAgVmVuZG9yOiBGVUpJVFNVICAg TW9kZWw6IE1BSjMxODJNUCAgICAgICAgIFJldjogNTUwOQpNYXIgMTAgMDg6 NDA6MTkgZmMybWUga2VybmVsOiAgIFR5cGU6ICAgRGlyZWN0LUFjY2VzcyAg ICAgICAgICAgICAgICAgICAgICBBTlNJIFNDU0kgcmV2aXNpb246IDAzCk1h ciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IHNjc2kwOkE6MDowOiBUYWdn ZWQgUXVldWluZyBlbmFibGVkLiAgRGVwdGggNApNYXIgMTAgMDg6NDA6MTkg ZmMybWUga2VybmVsOiBTQ1NJIGRldmljZSBzZGE6IDM1NTY2NDc4IDUxMi1i eXRlIGhkd3Igc2VjdG9ycyAoMTgyMTAgTUIpCk1hciAxMCAwODo0MDoxOSBm YzJtZSBrZXJuZWw6IFNDU0kgZGV2aWNlIHNkYTogZHJpdmUgY2FjaGU6IHdy aXRlIGJhY2sKTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogIHNkYTog c2RhMSBzZGEyIHNkYTMgc2RhNApNYXIgMTAgMDg6NDA6MTkgZmMybWUga2Vy bmVsOiBBdHRhY2hlZCBzY3NpIGRpc2sgc2RhIGF0IHNjc2kwLCBjaGFubmVs IDAsIGlkIDAsIGx1biAwCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6 ICAgVmVuZG9yOiBTRUFHQVRFICAgTW9kZWw6IFNUMTUyMzBOICAgICAgICAg IFJldjogMDYzOApNYXIgMTAgMDg6NDA6MTkgZmMybWUga2VybmVsOiAgIFR5 cGU6ICAgRGlyZWN0LUFjY2VzcyAgICAgICAgICAgICAgICAgICAgICBBTlNJ IFNDU0kgcmV2aXNpb246IDAyCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJu ZWw6IHNjc2kwOkE6MjowOiBUYWdnZWQgUXVldWluZyBlbmFibGVkLiAgRGVw dGggNApNYXIgMTAgMDg6NDA6MTkgZmMybWUga2VybmVsOiBTQ1NJIGRldmlj ZSBzZGI6IDgzODY3MzMgNTEyLWJ5dGUgaGR3ciBzZWN0b3JzICg0Mjk0IE1C KQpNYXIgMTAgMDg6NDA6MTkgZmMybWUga2VybmVsOiBTQ1NJIGRldmljZSBz ZGI6IGRyaXZlIGNhY2hlOiB3cml0ZSB0aHJvdWdoCk1hciAxMCAwODo0MDox OSBmYzJtZSBrZXJuZWw6ICBzZGI6IHNkYjEKTWFyIDEwIDA4OjQwOjE5IGZj Mm1lIGtlcm5lbDogQXR0YWNoZWQgc2NzaSBkaXNrIHNkYiBhdCBzY3NpMCwg Y2hhbm5lbCAwLCBpZCAyLCBsdW4gMApNYXIgMTAgMDg6NDA6MTkgZmMybWUg a2VybmVsOiAgIFZlbmRvcjogU0VBR0FURSAgIE1vZGVsOiBTVDE1MjMwTiAg ICAgICAgICBSZXY6IDA2MzgKTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5l bDogICBUeXBlOiAgIERpcmVjdC1BY2Nlc3MgICAgICAgICAgICAgICAgICAg ICAgQU5TSSBTQ1NJIHJldmlzaW9uOiAwMgpNYXIgMTAgMDg6NDA6MTkgZmMy bWUga2VybmVsOiBzY3NpMDpBOjQ6MDogVGFnZ2VkIFF1ZXVpbmcgZW5hYmxl ZC4gIERlcHRoIDQKTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogU0NT SSBkZXZpY2Ugc2RjOiA4Mzg2NzMzIDUxMi1ieXRlIGhkd3Igc2VjdG9ycyAo NDI5NCBNQikKTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogU0NTSSBk ZXZpY2Ugc2RjOiBkcml2ZSBjYWNoZTogd3JpdGUgdGhyb3VnaApNYXIgMTAg MDg6NDA6MTkgZmMybWUga2VybmVsOiAgc2RjOiBzZGMxCk1hciAxMCAwODo0 MDoxOSBmYzJtZSBrZXJuZWw6IEF0dGFjaGVkIHNjc2kgZGlzayBzZGMgYXQg c2NzaTAsIGNoYW5uZWwgMCwgaWQgNCwgbHVuIDAKTWFyIDEwIDA4OjQwOjE5 IGZjMm1lIGtlcm5lbDogICBWZW5kb3I6IFNFQUdBVEUgICBNb2RlbDogU1Qx NTIzME4gICAgICAgICAgUmV2OiAwNjM4Ck1hciAxMCAwODo0MDoxOSBmYzJt ZSBrZXJuZWw6ICAgVHlwZTogICBEaXJlY3QtQWNjZXNzICAgICAgICAgICAg ICAgICAgICAgIEFOU0kgU0NTSSByZXZpc2lvbjogMDIKTWFyIDEwIDA4OjQw OjE5IGZjMm1lIGtlcm5lbDogc2NzaTA6QTo1OjA6IFRhZ2dlZCBRdWV1aW5n IGVuYWJsZWQuICBEZXB0aCA0Ck1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJu ZWw6IFNDU0kgZGV2aWNlIHNkZDogODM4NjczMyA1MTItYnl0ZSBoZHdyIHNl Y3RvcnMgKDQyOTQgTUIpCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6 IFNDU0kgZGV2aWNlIHNkZDogZHJpdmUgY2FjaGU6IHdyaXRlIHRocm91Z2gK TWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogIHNkZDogc2RkMQpNYXIg MTAgMDg6NDA6MTkgZmMybWUga2VybmVsOiBBdHRhY2hlZCBzY3NpIGRpc2sg c2RkIGF0IHNjc2kwLCBjaGFubmVsIDAsIGlkIDUsIGx1biAwCk1hciAxMCAw ODo0MDoxOSBmYzJtZSBrZXJuZWw6IFNHSSBYRlMgd2l0aCBBQ0xzLCBsYXJn ZSBibG9jayBudW1iZXJzLCBubyBkZWJ1ZyBlbmFibGVkCk1hciAxMCAwODo0 MDoxOSBmYzJtZSBrZXJuZWw6IFNHSSBYRlMgUXVvdGEgTWFuYWdlbWVudCBz dWJzeXN0ZW0KTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogWEZTIG1v dW50aW5nIGZpbGVzeXN0ZW0gc2RhMgpNYXIgMTAgMDg6NDA6MTkgZmMybWUg a2VybmVsOiBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiAyNDRrIGZy ZWVkCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IGRyaXZlcnMvdXNi L2NvcmUvdXNiLmM6IHJlZ2lzdGVyZWQgbmV3IGRyaXZlciB1c2JmcwpNYXIg MTAgMDg6NDA6MTkgZmMybWUga2VybmVsOiBkcml2ZXJzL3VzYi9jb3JlL3Vz Yi5jOiByZWdpc3RlcmVkIG5ldyBkcml2ZXIgaHViCk1hciAxMCAwODo0MDox OSBmYzJtZSBrZXJuZWw6IGRyaXZlcnMvdXNiL2hvc3QvdWhjaS1oY2QuYzog VVNCIFVuaXZlcnNhbCBIb3N0IENvbnRyb2xsZXIgSW50ZXJmYWNlIGRyaXZl ciB2Mi4xCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IFBDSTogRm91 bmQgSVJRIDExIGZvciBkZXZpY2UgMDAwMDowMDowNy4yCk1hciAxMCAwODo0 MDoxOSBmYzJtZSBrZXJuZWw6IFBDSTogU2hhcmluZyBJUlEgMTEgd2l0aCAw MDAwOjAwOjExLjAKTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogUENJ OiBTaGFyaW5nIElSUSAxMSB3aXRoIDAwMDA6MDI6MGEuMApNYXIgMTAgMDg6 NDA6MTkgZmMybWUga2VybmVsOiB1aGNpX2hjZCAwMDAwOjAwOjA3LjI6IFVI Q0kgSG9zdCBDb250cm9sbGVyCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJu ZWw6IHVoY2lfaGNkIDAwMDA6MDA6MDcuMjogaXJxIDExLCBpbyBiYXNlIDAw MDBjY2UwCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IHVoY2lfaGNk IDAwMDA6MDA6MDcuMjogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWdu ZWQgYnVzIG51bWJlciAxCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6 IGh1YiAxLTA6MS4wOiBVU0IgaHViIGZvdW5kCk1hciAxMCAwODo0MDoxOSBm YzJtZSBrZXJuZWw6IGh1YiAxLTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkCk1h ciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IGRldmljZS1tYXBwZXI6IDQu MC4wLWlvY3RsICgyMDAzLTA2LTA0KSBpbml0aWFsaXNlZDogZG1AdWsuc2lz dGluYS5jb20KTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogbG9vcDog bG9hZGVkIChtYXggOCBkZXZpY2VzKQpNYXIgMTAgMDg6NDA6MTkgZmMybWUg a2VybmVsOiBoZGM6IEFUQVBJIDMyWCBDRC1ST00gZHJpdmUsIDI1NmtCIENh Y2hlLCBETUEKTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogVW5pZm9y bSBDRC1ST00gZHJpdmVyIFJldmlzaW9uOiAzLjIwCk1hciAxMCAwODo0MDox OSBmYzJtZSBrZXJuZWw6IEFkZGluZyA3ODcxNzZrIHN3YXAgb24gL2Rldi9z ZGEzLiAgUHJpb3JpdHk6LTEgZXh0ZW50czoxCk1hciAxMCAwODo0MDoxOSBm YzJtZSBrZXJuZWw6IFhGUyBtb3VudGluZyBmaWxlc3lzdGVtIHNkYTEKTWFy IDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogWEZTIG1vdW50aW5nIGZpbGVz eXN0ZW0gZG0tNQpNYXIgMTAgMDg6NDA6MTkgZmMybWUga2VybmVsOiBYRlMg bW91bnRpbmcgZmlsZXN5c3RlbSBkbS0zCk1hciAxMCAwODo0MDoxOSBmYzJt ZSBrZXJuZWw6IFhGUyBtb3VudGluZyBmaWxlc3lzdGVtIGRtLTQKTWFyIDEw IDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogWEZTIG1vdW50aW5nIGZpbGVzeXN0 ZW0gZG0tMQpNYXIgMTAgMDg6NDA6MTkgZmMybWUga2VybmVsOiBYRlMgbW91 bnRpbmcgZmlsZXN5c3RlbSBkbS0yCk1hciAxMCAwODo0MDoxOSBmYzJtZSBr ZXJuZWw6IFtkcm1dIEluaXRpYWxpemVkIHJhZGVvbiAxLjkuMCAyMDAyMDgy OCBvbiBtaW5vciAwCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IFBD STogRm91bmQgSVJRIDEwIGZvciBkZXZpY2UgMDAwMDowMDowZS4wCk1hciAx MCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IGF0a2JkLmM6IFVua25vd24ga2V5 IHJlbGVhc2VkICh0cmFuc2xhdGVkIHNldCAyLCBjb2RlIDB4N2Egb24gaXNh MDA2MC9zZXJpbzApLgpNYXIgMTAgMDg6NDA6MTkgZmMybWUga2VybmVsOiBh dGtiZC5jOiBUaGlzIGlzIGFuIFhGcmVlODYgYnVnLiBJdCBzaG91bGRuJ3Qg YWNjZXNzIGhhcmR3YXJlIGRpcmVjdGx5LgpNYXIgMTAgMDg6NDA6MTkgZmMy bWUga2VybmVsOiBhdGtiZC5jOiBVbmtub3duIGtleSByZWxlYXNlZCAodHJh bnNsYXRlZCBzZXQgMiwgY29kZSAweDdhIG9uIGlzYTAwNjAvc2VyaW8wKS4K TWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogYXRrYmQuYzogVGhpcyBp cyBhbiBYRnJlZTg2IGJ1Zy4gSXQgc2hvdWxkbid0IGFjY2VzcyBoYXJkd2Fy ZSBkaXJlY3RseS4KTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogcXVv dGFvbjogbnVtZXJpY2FsIHN5c2N0bCA1IDE2IDggaXMgb2Jzb2xldGUuCk1h ciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IElBLTMyIE1pY3JvY29kZSBV cGRhdGUgRHJpdmVyOiB2MS4xMyA8dGlncmFuQHZlcml0YXMuY29tPgpNYXIg MTAgMDg6NDA6MTkgZmMybWUga2VybmVsOiBtaWNyb2NvZGU6IENQVTAgdXBk YXRlZCBmcm9tIHJldmlzaW9uIDB4MCB0byAweDEzLCBkYXRlID0gMDIwNjIw MDEgCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IGt1ZHp1OiBudW1l cmljYWwgc3lzY3RsIDEgMjMgaXMgb2Jzb2xldGUuCk1hciAxMCAwODo0MDox OSBmYzJtZSBrZXJuZWw6IHBhcnBvcnQwOiBQQy1zdHlsZSBhdCAweDM3OCAo MHg3NzgpIFtQQ1NQUCxUUklTVEFURSxFUFBdCk1hciAxMCAwODo0MDoxOSBm YzJtZSBrZXJuZWw6IHBhcnBvcnQwOiBpcnEgNyBkZXRlY3RlZApNYXIgMTAg MDg6NDA6MTkgZmMybWUga2VybmVsOiBBdHRhY2hlZCBzY3NpIGdlbmVyaWMg c2cwIGF0IHNjc2kwLCBjaGFubmVsIDAsIGlkIDAsIGx1biAwLCAgdHlwZSAw Ck1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IEF0dGFjaGVkIHNjc2kg Z2VuZXJpYyBzZzEgYXQgc2NzaTAsIGNoYW5uZWwgMCwgaWQgMiwgbHVuIDAs ICB0eXBlIDAKTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogQXR0YWNo ZWQgc2NzaSBnZW5lcmljIHNnMiBhdCBzY3NpMCwgY2hhbm5lbCAwLCBpZCA0 LCBsdW4gMCwgIHR5cGUgMApNYXIgMTAgMDg6NDA6MTkgZmMybWUga2VybmVs OiBBdHRhY2hlZCBzY3NpIGdlbmVyaWMgc2czIGF0IHNjc2kwLCBjaGFubmVs IDAsIGlkIDUsIGx1biAwLCAgdHlwZSAwCk1hciAxMCAwODo0MDoxOSBmYzJt ZSBrZXJuZWw6IGluc2VydGluZyBmbG9wcHkgZHJpdmVyIGZvciAyLjYuMS0x LjY1Ck1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IEZsb3BweSBkcml2 ZShzKTogZmQwIGlzIDEuNDRNCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJu ZWw6IEZEQyAwIGlzIGEgTmF0aW9uYWwgU2VtaWNvbmR1Y3RvciBQQzg3MzA2 Ck1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IGt1ZHp1OiBudW1lcmlj YWwgc3lzY3RsIDEgNDkgaXMgb2Jzb2xldGUuCk1hciAxMCAwODo0MDoxOSBm YzJtZSBrZXJuZWw6IFBDSTogRm91bmQgSVJRIDExIGZvciBkZXZpY2UgMDAw MDowMDoxMS4wCk1hciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IFBDSTog U2hhcmluZyBJUlEgMTEgd2l0aCAwMDAwOjAwOjA3LjIKTWFyIDEwIDA4OjQw OjE5IGZjMm1lIGtlcm5lbDogUENJOiBTaGFyaW5nIElSUSAxMSB3aXRoIDAw MDA6MDI6MGEuMApNYXIgMTAgMDg6NDA6MTkgZmMybWUga2VybmVsOiAzYzU5 eDogRG9uYWxkIEJlY2tlciBhbmQgb3RoZXJzLiB3d3cuc2N5bGQuY29tL25l dHdvcmsvdm9ydGV4Lmh0bWwKTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5l bDogMDAwMDowMDoxMS4wOiAzQ29tIFBDSSAzYzkwNSBCb29tZXJhbmcgMTAw YmFzZVR4IGF0IDB4Y2M4MC4gVmVycyBMSzEuMS4xOQpNYXIgMTAgMDg6NDA6 MTkgZmMybWUga2VybmVsOiAgKioqSU5WQUxJRCBDSEVDS1NVTSAwMDNlKioq IDw3PmRpdmVydDogYWxsb2NhdGluZyBkaXZlcnRfYmxrIGZvciBldGgwCk1h ciAxMCAwODo0MDoxOSBmYzJtZSBrZXJuZWw6IGV0aDA6IERyb3BwaW5nIE5F VElGX0ZfU0cgc2luY2Ugbm8gY2hlY2tzdW0gZmVhdHVyZS4KTWFyIDEwIDA4 OjQwOjE5IGZjMm1lIGtlcm5lbDoga3VkenU6IG51bWVyaWNhbCBzeXNjdGwg MSA0OSBpcyBvYnNvbGV0ZS4KTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5l bDogaXBfdGFibGVzOiAoQykgMjAwMC0yMDAyIE5ldGZpbHRlciBjb3JlIHRl YW0KTWFyIDEwIDA4OjQwOjE5IGZjMm1lIGtlcm5lbDogaXBfY29ubnRyYWNr IHZlcnNpb24gMi4xICgzMDcxIGJ1Y2tldHMsIDI0NTY4IG1heCkgLSAzMjQg Ynl0ZXMgcGVyIGNvbm50cmFjawpNYXIgMTAgMDg6NDA6MTkgZmMybWUgcG9y dG1hcDogcG9ydG1hcCBzdGFydHVwIHN1Y2NlZWRlZApNYXIgMTAgMDg6NDA6 MjAgZmMybWUgcnBjLnN0YXRkWzEwMzFdOiBWZXJzaW9uIDEuMC42IFN0YXJ0 aW5nCk1hciAxMCAwODo0MDoyMCBmYzJtZSBuZnNsb2NrOiBycGMuc3RhdGQg c3RhcnR1cCBzdWNjZWVkZWQKTWFyIDEwIDA4OjQwOjE3IGZjMm1lIGlmdXA6 ICBkb25lLiAKTWFyIDEwIDA4OjQwOjE3IGZjMm1lIG5ldHdvcms6IEJyaW5n aW5nIHVwIGludGVyZmFjZSBldGgwOiAgc3VjY2VlZGVkIApNYXIgMTAgMDg6 NDA6MjAgZmMybWUgcmFuZG9tOiBJbml0aWFsaXppbmcgcmFuZG9tIG51bWJl ciBnZW5lcmF0b3I6ICBzdWNjZWVkZWQKTWFyIDEwIDA4OjQwOjIwIGZjMm1l IHJjOiBTdGFydGluZyBwY21jaWE6ICBzdWNjZWVkZWQKTWFyIDEwIDA4OjQw OjIwIGZjMm1lIG5ldGZzOiBNb3VudGluZyBvdGhlciBmaWxlc3lzdGVtczog IHN1Y2NlZWRlZApNYXIgMTAgMDg6NDA6MjEgZmMybWUgYXBtZFsxMDg2XTog VmVyc2lvbiAzLjAuMiAoQVBNIEJJT1MgMS4yLCBMaW51eCBkcml2ZXIgMS4x NmFjKQpNYXIgMTAgMDg6NDA6MjEgZmMybWUgYXBtZDogYXBtZCBzdGFydHVw IHN1Y2NlZWRlZApNYXIgMTAgMDg6NDA6MjEgZmMybWUgYXV0b2ZzOiBhdXRv bW91bnQgc3RhcnR1cCBzdWNjZWVkZWQKTWFyIDEwIDA4OjQwOjIxIGZjMm1l IHNtYXJ0ZFsxMTI0XTogc21hcnRkIHZlcnNpb24gNS4yMSBDb3B5cmlnaHQg KEMpIDIwMDItMyBCcnVjZSBBbGxlbiAKTWFyIDEwIDA4OjQwOjIxIGZjMm1l IHNtYXJ0ZFsxMTI0XTogSG9tZSBwYWdlIGlzIGh0dHA6Ly9zbWFydG1vbnRv b2xzLnNvdXJjZWZvcmdlLm5ldC8gIApNYXIgMTAgMDg6NDA6MjEgZmMybWUg c21hcnRkWzExMjRdOiBPcGVuZWQgY29uZmlndXJhdGlvbiBmaWxlIC9ldGMv c21hcnRkLmNvbmYgCk1hciAxMCAwODo0MDoyMSBmYzJtZSBzbWFydGRbMTEy NF06IENvbmZpZ3VyYXRpb24gZmlsZSAvZXRjL3NtYXJ0ZC5jb25mIHBhcnNl ZC4gCk1hciAxMCAwODo0MDoyMSBmYzJtZSBtb2Rwcm9iZTogV0FSTklORzog L2V0Yy9tb2Rwcm9iZS5jb25mIGxpbmUgMzogaWdub3JpbmcgYmFkIGxpbmUg c3RhcnRpbmcgd2l0aCAncG9zdC1pbnN0YWxsJyAKTWFyIDEwIDA4OjQwOjIx IGZjMm1lIG1vZHByb2JlOiBXQVJOSU5HOiAvZXRjL21vZHByb2JlLmNvbmYg bGluZSAzOiBpZ25vcmluZyBiYWQgbGluZSBzdGFydGluZyB3aXRoICdwb3N0 LWluc3RhbGwnIApNYXIgMTAgMDg6NDA6MjIgZmMybWUgc21hcnRkWzExMjRd OiBEZXZpY2U6IC9kZXYvaGRhLCBObyBzdWNoIGRldmljZSBvciBhZGRyZXNz LCBvcGVuKCkgZmFpbGVkIApNYXIgMTAgMDg6NDA6MjIgZmMybWUgc21hcnRk WzExMjRdOiBVbmFibGUgdG8gcmVnaXN0ZXIgQVRBIGRldmljZSAvZGV2L2hk YSBhdCBsaW5lIDMwIG9mIGZpbGUgL2V0Yy9zbWFydGQuY29uZiAKTWFyIDEw IDA4OjQwOjIyIGZjMm1lIHNtYXJ0ZFsxMTI0XTogVW5hYmxlIHRvIHJlZ2lz dGVyIGRldmljZSAvZGV2L2hkYSAobm8gRGlyZWN0aXZlIC1kIHJlbW92YWJs ZSkuIEV4aXRpbmcuIApNYXIgMTAgMDg6NDA6MjIgZmMybWUgc21hcnRkOiBz bWFydGQgc3RhcnR1cCBmYWlsZWQKTWFyIDEwIDA4OjQwOjIyIGZjMm1lIGFw bWRbMTA4Nl06IENoYXJnZTogKiAqICogKC0xJSB1bmtub3duKQpNYXIgMTAg MDg6NDA6MjQgZmMybWUgbW9kcHJvYmU6IFdBUk5JTkc6IC9ldGMvbW9kcHJv YmUuY29uZiBsaW5lIDM6IGlnbm9yaW5nIGJhZCBsaW5lIHN0YXJ0aW5nIHdp dGggJ3Bvc3QtaW5zdGFsbCcgCk1hciAxMCAwODo0MDoyNCBmYzJtZSBrZXJu ZWw6IGxwMDogdXNpbmcgcGFycG9ydDAgKHBvbGxpbmcpLgpNYXIgMTAgMDg6 NDA6MjQgZmMybWUga2VybmVsOiBscDA6IGNvbnNvbGUgcmVhZHkKTWFyIDEw IDA4OjQwOjI0IGZjMm1lIG1vZHByb2JlOiBXQVJOSU5HOiAvZXRjL21vZHBy b2JlLmNvbmYgbGluZSAzOiBpZ25vcmluZyBiYWQgbGluZSBzdGFydGluZyB3 aXRoICdwb3N0LWluc3RhbGwnIApNYXIgMTAgMDg6NDA6MzEgZmMybWUgbGFz dCBtZXNzYWdlIHJlcGVhdGVkIDc5IHRpbWVzCk1hciAxMCAwODo0MDozMSBm YzJtZSBjdXBzOiBjdXBzZCBzdGFydHVwIHN1Y2NlZWRlZApNYXIgMTAgMDg6 NDA6MzIgZmMybWUgc3NoZDogUlNBMSBrZXkgZ2VuZXJhdGlvbiBzdWNjZWVk ZWQKTWFyIDEwIDA4OjQwOjMzIGZjMm1lIHNzaGQ6IFJTQSBrZXkgZ2VuZXJh dGlvbiBzdWNjZWVkZWQKTWFyIDEwIDA4OjQwOjM5IGZjMm1lIHNzaGQ6IERT QSBrZXkgZ2VuZXJhdGlvbiBzdWNjZWVkZWQKTWFyIDEwIDA4OjQwOjM5IGZj Mm1lIG1vZHByb2JlOiBXQVJOSU5HOiAvZXRjL21vZHByb2JlLmNvbmYgbGlu ZSAzOiBpZ25vcmluZyBiYWQgbGluZSBzdGFydGluZyB3aXRoICdwb3N0LWlu c3RhbGwnIApNYXIgMTAgMDg6NDA6MzkgZmMybWUgbW9kcHJvYmU6IFdBUk5J Tkc6IC9ldGMvbW9kcHJvYmUuY29uZiBsaW5lIDM6IGlnbm9yaW5nIGJhZCBs aW5lIHN0YXJ0aW5nIHdpdGggJ3Bvc3QtaW5zdGFsbCcgCk1hciAxMCAwODo0 MDozOSBmYzJtZSBrZXJuZWw6IE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBm YW1pbHkgMTAKTWFyIDEwIDA4OjQwOjM5IGZjMm1lIGtlcm5lbDogRGlzYWJs ZWQgUHJpdmFjeSBFeHRlbnNpb25zIG9uIGRldmljZSBjMDM5ZDk4MChsbykK TWFyIDEwIDA4OjQwOjM5IGZjMm1lIGtlcm5lbDogSVB2NiBvdmVyIElQdjQg dHVubmVsaW5nIGRyaXZlcgpNYXIgMTAgMDg6NDA6NDAgZmMybWUgc3NoZDog IHN1Y2NlZWRlZApNYXIgMTAgMDg6NDA6NDAgZmMybWUgeGluZXRkOiB4aW5l dGQgc3RhcnR1cCBzdWNjZWVkZWQKTWFyIDEwIDA4OjQwOjQxIGZjMm1lIHNl bmRtYWlsOiBzZW5kbWFpbCBzdGFydHVwIHN1Y2NlZWRlZApNYXIgMTAgMDg6 NDA6NDIgZmMybWUgc2VuZG1haWw6IHNtLWNsaWVudCBzdGFydHVwIHN1Y2Nl ZWRlZApNYXIgMTAgMDg6NDA6NDIgZmMybWUgeGluZXRkWzEzODVdOiB4aW5l dGQgVmVyc2lvbiAyLjMuMTIgc3RhcnRlZCB3aXRoIGxpYndyYXAgbG9hZGF2 ZyBvcHRpb25zIGNvbXBpbGVkIGluLgpNYXIgMTAgMDg6NDA6NDIgZmMybWUg eGluZXRkWzEzODVdOiBTdGFydGVkIHdvcmtpbmc6IDEgYXZhaWxhYmxlIHNl cnZpY2UKTWFyIDEwIDA4OjQwOjQyIGZjMm1lIGdwbTogZ3BtIHN0YXJ0dXAg c3VjY2VlZGVkCk1hciAxMCAwODo0MDo0MyBmYzJtZSBjcm9uZDogY3JvbmQg c3RhcnR1cCBzdWNjZWVkZWQKTWFyIDEwIDA4OjQwOjQzIGZjMm1lIHhmczog eGZzIHN0YXJ0dXAgc3VjY2VlZGVkCk1hciAxMCAwODo0MDo0NCBmYzJtZSBh bmFjcm9uOiBhbmFjcm9uIHN0YXJ0dXAgc3VjY2VlZGVkCk1hciAxMCAwODo0 MDo0NCBmYzJtZSB4ZnM6IGlnbm9yaW5nIGZvbnQgcGF0aCBlbGVtZW50IC91 c3IvWDExUjYvbGliL1gxMS9mb250cy9jeXJpbGxpYyAodW5yZWFkYWJsZSkg Ck1hciAxMCAwODo0MDo0NCBmYzJtZSBhdGQ6IGF0ZCBzdGFydHVwIHN1Y2Nl ZWRlZApNYXIgMTAgMDg6NDA6NDUgZmMybWUgZ2NvbmZkIChyb290LTE0OTYp OiBzdGFydGluZyAodmVyc2lvbiAyLjUuMSksIHBpZCAxNDk2IHVzZXIgJ3Jv b3QnCk1hciAxMCAwODo0MDo0NiBmYzJtZSBnY29uZmQgKHJvb3QtMTQ5Nik6 IFJlc29sdmVkIGFkZHJlc3MgInhtbDpyZWFkb25seTovZXRjL2djb25mL2dj b25mLnhtbC5tYW5kYXRvcnkiIHRvIGEgcmVhZC1vbmx5IGNvbmZpZyBzb3Vy Y2UgYXQgcG9zaXRpb24gMApNYXIgMTAgMDg6NDA6NDYgZmMybWUgZ2NvbmZk IChyb290LTE0OTYpOiBSZXNvbHZlZCBhZGRyZXNzICJ4bWw6cmVhZHdyaXRl Oi9yb290Ly5nY29uZiIgdG8gYSB3cml0YWJsZSBjb25maWcgc291cmNlIGF0 IHBvc2l0aW9uIDEKTWFyIDEwIDA4OjQwOjQ2IGZjMm1lIGdjb25mZCAocm9v dC0xNDk2KTogUmVzb2x2ZWQgYWRkcmVzcyAieG1sOnJlYWRvbmx5Oi9ldGMv Z2NvbmYvZ2NvbmYueG1sLmRlZmF1bHRzIiB0byBhIHJlYWQtb25seSBjb25m aWcgc291cmNlIGF0IHBvc2l0aW9uIDIKTWFyIDEwIDA4OjQwOjU1IGZjMm1l IGtlcm5lbDogcHl0aG9uMjogbnVtZXJpY2FsIHN5c2N0bCAxIDIzIGlzIG9i c29sZXRlLgpNYXIgMTAgMDg6NDA6NTggZmMybWUga2VybmVsOiBkZGNwcm9i ZTogbnVtZXJpY2FsIHN5c2N0bCAxIDIzIGlzIG9ic29sZXRlLgpNYXIgMTAg MDg6NDA6NTkgZmMybWUga2VybmVsOiBweXRob24yOiBudW1lcmljYWwgc3lz Y3RsIDEgMjMgaXMgb2Jzb2xldGUuCk1hciAxMCAwODo0MTowMSBmYzJtZSBr ZXJuZWw6IGRkY3Byb2JlOiBudW1lcmljYWwgc3lzY3RsIDEgMjMgaXMgb2Jz b2xldGUuCk1hciAxMCAwODo0MTowMiBmYzJtZSBrZXJuZWw6IHB5dGhvbjI6 IG51bWVyaWNhbCBzeXNjdGwgMSAyMyBpcyBvYnNvbGV0ZS4KTWFyIDEwIDA4 OjQxOjA0IGZjMm1lIGtlcm5lbDogZGRjcHJvYmU6IG51bWVyaWNhbCBzeXNj dGwgMSAyMyBpcyBvYnNvbGV0ZS4KTWFyIDEwIDA4OjQxOjA2IGZjMm1lIGtl cm5lbDogcHl0aG9uMjogbnVtZXJpY2FsIHN5c2N0bCAxIDIzIGlzIG9ic29s ZXRlLgpNYXIgMTAgMDg6NDE6MDYgZmMybWUga2VybmVsOiBweXRob24yOiBu dW1lcmljYWwgc3lzY3RsIDEgMjMgaXMgb2Jzb2xldGUuCk1hciAxMCAwODo0 MjowMSBmYzJtZSBudHBkOiAgc3VjY2VlZGVkCk1hciAxMCAwODo0MjowMSBm YzJtZSBudHBkOiAgc3VjY2VlZGVkCk1hciAxMCAwODozNjo0NyBmYzJtZSBu dHBkYXRlWzE1NDZdOiBzdGVwIHRpbWUgc2VydmVyIDE5OC44Mi4xNjIuMjEz IG9mZnNldCAtMzEzLjYzMjI2OCBzZWMKTWFyIDEwIDA4OjM2OjQ3IGZjMm1l IG50cGQ6ICBzdWNjZWVkZWQKTWFyIDEwIDA4OjM2OjQ3IGZjMm1lIG50cGQ6 IG50cGQgc3RhcnR1cCBzdWNjZWVkZWQKTWFyIDEwIDA4OjM2OjQ3IGZjMm1l IG50cGRbMTU1MF06IG50cGQgNC4yLjBAMS4xMTYxLXIgV2VkIEphbiAyOCAw OToyMDo1MiBFU1QgMjAwNCAoMSkKTWFyIDEwIDA4OjM2OjQ4IGZjMm1lIG50 cGRbMTU1MF06IHByZWNpc2lvbiA9IDIuMDAwIHVzZWMKTWFyIDEwIDA4OjM2 OjQ4IGZjMm1lIG50cGRbMTU1MF06IGtlcm5lbCB0aW1lIHN5bmMgc3RhdHVz IDAwNDAKTWFyIDEwIDA4OjM2OjQ4IGZjMm1lIG50cGRbMTU1MF06IGZyZXF1 ZW5jeSBpbml0aWFsaXplZCAwLjAwMCBQUE0gZnJvbSAvdmFyL2xpYi9udHAv ZHJpZnQKTWFyIDEwIDA4OjM2OjQ4IGZjMm1lIG50cGRbMTU1MF06IGNvbmZp Z3VyZToga2V5d29yZCAiYXV0aGVudGljYXRlIiB1bmtub3duLCBsaW5lIGln bm9yZWQKTWFyIDEwIDA4OjM3OjM1IGZjMm1lIGZpcnN0Ym9vdDogIHN1Y2Nl ZWRlZApNYXIgMTAgMDg6Mzc6MzUgZmMybWUgcmVhZGFoZWFkOiBTdGFydGlu ZyBiYWNrZ3JvdW5kIHJlYWRhaGVhZDogCk1hciAxMCAwODozNzozNiBmYzJt ZSByYzogU3RhcnRpbmcgcmVhZGFoZWFkOiAgc3VjY2VlZGVkCk1hciAxMCAw ODozNzozNiBmYzJtZSBtZXNzYWdlYnVzOiBtZXNzYWdlYnVzIHN0YXJ0dXAg c3VjY2VlZGVkCk1hciAxMCAwODozNzozOCBmYzJtZSBpbml0OiBvcGVuKC9k ZXYvcHRzLzApOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Ck1hciAxMCAw ODozNzozOCBmYzJtZSBpbml0OiBvcGVuKC9kZXYvcHRzLzApOiBObyBzdWNo IGZpbGUgb3IgZGlyZWN0b3J5Ck1hciAxMCAwODozNzo0NCBmYzJtZSBrZXJu ZWw6IFBDSTogRm91bmQgSVJRIDEwIGZvciBkZXZpY2UgMDAwMDowMDowZS4w Ck1hciAxMCAwODozNzo0NCBmYzJtZSBrZXJuZWw6IGF0a2JkLmM6IFVua25v d24ga2V5IHJlbGVhc2VkICh0cmFuc2xhdGVkIHNldCAyLCBjb2RlIDB4N2Eg b24gaXNhMDA2MC9zZXJpbzApLgpNYXIgMTAgMDg6Mzc6NDQgZmMybWUga2Vy bmVsOiBhdGtiZC5jOiBUaGlzIGlzIGFuIFhGcmVlODYgYnVnLiBJdCBzaG91 bGRuJ3QgYWNjZXNzIGhhcmR3YXJlIGRpcmVjdGx5LgpNYXIgMTAgMDg6Mzc6 NDQgZmMybWUga2VybmVsOiBhdGtiZC5jOiBVbmtub3duIGtleSByZWxlYXNl ZCAodHJhbnNsYXRlZCBzZXQgMiwgY29kZSAweDdhIG9uIGlzYTAwNjAvc2Vy aW8wKS4KTWFyIDEwIDA4OjM3OjQ0IGZjMm1lIGtlcm5lbDogYXRrYmQuYzog VGhpcyBpcyBhbiBYRnJlZTg2IGJ1Zy4gSXQgc2hvdWxkbid0IGFjY2VzcyBo YXJkd2FyZSBkaXJlY3RseS4KTWFyIDEwIDA4OjM4OjAyIGZjMm1lIGdjb25m ZCAocm9vdC0xNDk2KTogR0NvbmYgc2VydmVyIGlzIG5vdCBpbiB1c2UsIHNo dXR0aW5nIGRvd24uCk1hciAxMCAwODozODowMiBmYzJtZSBnY29uZmQgKHJv b3QtMTQ5Nik6IEV4aXRpbmcKTWFyIDEwIDA4OjM4OjA2IGZjMm1lIGdkbShw YW1fdW5peClbMTYzOF06IHNlc3Npb24gb3BlbmVkIGZvciB1c2VyIG11cnRo eSBieSAodWlkPTApCk1hciAxMCAwODozODoxMSBmYzJtZSBnY29uZmQgKG11 cnRoeS0xNzA1KTogc3RhcnRpbmcgKHZlcnNpb24gMi41LjEpLCBwaWQgMTcw NSB1c2VyICdtdXJ0aHknCk1hciAxMCAwODozODoxMSBmYzJtZSBnY29uZmQg KG11cnRoeS0xNzA1KTogUmVzb2x2ZWQgYWRkcmVzcyAieG1sOnJlYWRvbmx5 Oi9ldGMvZ2NvbmYvZ2NvbmYueG1sLm1hbmRhdG9yeSIgdG8gYSByZWFkLW9u bHkgY29uZmlnIHNvdXJjZSBhdCBwb3NpdGlvbiAwCk1hciAxMCAwODozODox MSBmYzJtZSBnY29uZmQgKG11cnRoeS0xNzA1KTogUmVzb2x2ZWQgYWRkcmVz cyAieG1sOnJlYWR3cml0ZTovaG9tZS9tdXJ0aHkvLmdjb25mIiB0byBhIHdy aXRhYmxlIGNvbmZpZyBzb3VyY2UgYXQgcG9zaXRpb24gMQpNYXIgMTAgMDg6 Mzg6MTEgZmMybWUgZ2NvbmZkIChtdXJ0aHktMTcwNSk6IFJlc29sdmVkIGFk ZHJlc3MgInhtbDpyZWFkb25seTovZXRjL2djb25mL2djb25mLnhtbC5kZWZh dWx0cyIgdG8gYSByZWFkLW9ubHkgY29uZmlnIHNvdXJjZSBhdCBwb3NpdGlv biAyCk1hciAxMCAwODozODoxMiBmYzJtZSBib25vYm8tYWN0aXZhdGlvbi1z ZXJ2ZXIgKG11cnRoeS0xNzEwKTogaWlkIE9BRklJRDpCcm9rZW5Ob1R5cGU6 MjAwMDA4MDggaGFzIGEgTlVMTCB0eXBlCk1hciAxMCAwODozODoxMiBmYzJt ZSBib25vYm8tYWN0aXZhdGlvbi1zZXJ2ZXIgKG11cnRoeS0xNzEwKTogaW52 YWxpZCBjaGFyYWN0ZXIgJyMnIGluIGlpZCAnT0FGSUlEOlRoaXMjISElJGlp ZCVeJCVffH4hT0FGSUlEX0NvbnRhaW5zQmFkQ2hhcnMnCk1hciAxMCAwODoz ODoxNiBmYzJtZSB4aW5ldGRbMTcyMV06IHdhcm5pbmc6IGNhbid0IGdldCBj bGllbnQgYWRkcmVzczogVHJhbnNwb3J0IGVuZHBvaW50IGlzIG5vdCBjb25u ZWN0ZWQKTWFyIDEwIDA4OjM4OjE5IGZjMm1lIG1vZHByb2JlOiBXQVJOSU5H OiAvZXRjL21vZHByb2JlLmNvbmYgbGluZSAzOiBpZ25vcmluZyBiYWQgbGlu ZSBzdGFydGluZyB3aXRoICdwb3N0LWluc3RhbGwnIApNYXIgMTAgMDg6Mzg6 NDEgZmMybWUgbGFzdCBtZXNzYWdlIHJlcGVhdGVkIDggdGltZXMKTWFyIDEw IDA4OjQ1OjIzIGZjMm1lIG50cGRbMTU1MF06IHN5bmNocm9uaXplZCB0byAx OTguODIuMTYyLjIxMywgc3RyYXR1bT0yCk1hciAxMCAwODo0NToyMyBmYzJt ZSBudHBkWzE1NTBdOiBrZXJuZWwgdGltZSBzeW5jIGRpc2FibGVkIDAwNDEK TWFyIDEwIDA4OjUwOjQyIGZjMm1lIHNzaGQocGFtX3VuaXgpWzE5MjldOiBz ZXNzaW9uIG9wZW5lZCBmb3IgdXNlciBtdXJ0aHkgYnkgKHVpZD01MDApCk1h ciAxMCAwODo1MTowNCBmYzJtZSBzc2hkKHBhbV91bml4KVsxOTI5XTogc2Vz c2lvbiBjbG9zZWQgZm9yIHVzZXIgbXVydGh5Ck1hciAxMCAwOTowMDoyMyBm YzJtZSBudHBkWzE1NTBdOiBrZXJuZWwgdGltZSBzeW5jIGVuYWJsZWQgMDAw MQpNYXIgMTAgMDk6MDQ6NDMgZmMybWUgbnRwZFsxNTUwXTogbm8gc2VydmVy cyByZWFjaGFibGUKTWFyIDEwIDA5OjA1OjQ5IGZjMm1lIG50cGRbMTU1MF06 IHN5bmNocm9uaXplZCB0byAxOTguODIuMTYyLjIxMywgc3RyYXR1bT0yCk1h ciAxMCAwOTowNjo1MyBmYzJtZSBzdShwYW1fdW5peClbMjA0Ml06IHNlc3Np b24gb3BlbmVkIGZvciB1c2VyIHJvb3QgYnkgbXVydGh5KHVpZD01MDApCg== ------_=_NextPart_001_01C406BC.F2B6A424-- From owner-linux-xfs@oss.sgi.com Wed Mar 10 09:20:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 09:21:05 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2AHKvKO030800 for ; Wed, 10 Mar 2004 09:20:57 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2AHCKdi006544 for ; Wed, 10 Mar 2004 11:12:20 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2AHCKKe35224830; Wed, 10 Mar 2004 11:12:20 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i2AHCJEq1767154; Wed, 10 Mar 2004 11:12:19 -0600 (CST) Subject: Re: ran into rare bug: "unable to verify superblock, continuing..." From: Eric Sandeen To: Errikos Pitsos {secure} Cc: "linux-xfs@oss.sgi.com "{unsecure} In-Reply-To: <404F481C.5090801@leogic.com> References: <404ED170.9000601@leogic.com> <1078936989.18173.13.camel@stout.americas.sgi.com> <404F481C.5090801@leogic.com> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1078938738.18173.19.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 10 Mar 2004 11:12:19 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2407 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 7829 Lines: 220 Well, one way or another you got block 0 clobbered... I'm guessing that perhaps xfs_repair is finding an older superblock from your previous mkfs, and getting confused. I'd let repair run to completion and see if it finds other superblocks that are valid... that's my best suggestion for now. On Wed, 2004-03-10 at 10:53, Errikos Pitsos {secure} wrote: > the machine has three partitions. > 1 boot > 2 swap > 3 root > > it's a laptop hd. > > I took it out of the one laptop and put it into another because I wanted > to transfer 50gb onto it and because I wanted to change partition 2 and > 3. So resized 2 and 3, which naturally deleted the data on both of them. I hope you re-ran mkfs at this point? > Mounted part3 and copied 50gb of data onto it. Then I shutdown the > machine(where I didn't find a syslog entry for the xfs part being > properly unmounted, don't know whether this is normally always logged) No, xfs doesn't log clean unmounts in the syslog. > and put the hd back into the original laptop. She booted fine, grub, > everything, but during kernel loading isn't able to mount the xfs. > partition(root) I took the hd out again and tried mounting the hd on the > system where I had copied the stuff from. Nothing works there either, so > that's where I am now. I assume that if you repartitioned part3 (root), you probably also re-ran your bootloader. Again, did you tell the bootloader to land on the mbr, or on a partition? -Eric > e > > > Eric Sandeen {u} wrote: > > Any chance you put your bootloader on the root partition, rather than > > the mbr? XFS uses block zero, as would the bootloader if you put it > > there. > > > > Still, not sure offhand why repair did not fix things up. > > > > On Wed, 2004-03-10 at 02:27, Errikos Pitsos {secure} wrote: > > > >>Hi! > >> > >>Seems like I ran into a known problem wrt to "unable to verify > >>superblock, continuing..." > >>http://oss.sgi.com/projects/xfs/faq.html#xfsmountfail > >> > >>I can't mount the xfs fs. > >>I can't repair the xfs fs. > >>Yes, this is my root partition, this is a new system I was setting up. > >>I don't know what caused the trouble, but it seems that somehow the > >>system was not properly unmounted. > >>Using xfs_repai without "L" doesn't change anything. > >>So if I can help finding that bug tell me. > >>I am using Gentoo and had a 2.4.24-xfs-r3 on there, syslog says: > >>Mar 10 07:56:43 leonzwei SGI XFS snapshot-2.4.23-2003-12-01_00:33_UTC > >>with no debug enabled > >> > >>For some reason it seems that the XFS was not cleanly unmounted, not > >>sure though. The system was cleanly shutdown, but I didn't find a: > >> Mar 10 03:47:25 leonzwei Ending clean XFS mount for filesystem: ide1(22,3) > >> > >>in there which I had before. > >> > >> > >>syslog shows these here when I try to mount the partition. > >>Mar 10 08:03:37 leonzwei XFS: bad magic number > >>Mar 10 08:03:37 leonzwei XFS: SB validate failed > >> > >> > >> > >>here some console output: > >> > >>leonzwei root # xfs_repair -nLv /dev/hdc3 > >>Phase 1 - find and verify superblock... > >>bad primary superblock - bad magic number !!! > >> > >>attempting to find secondary superblock... > >>........................................................................................................... > >> > >> > >>.....................found candidate secondary superblock... > >>error reading superblock 54 -- seek to offset 57982058496 failed > >>unable to verify superblock, continuing... > >>........................................................................................................... > >> > >> > >>........................................................................................................... > >> > >> > >>........................................................................................................... > >> > >> > >>........................................................................................................... > >> > >> > >>........................................................................................................... > >> > >> > >>........................................................................................................... > >> > >> > >>........................................................................................................... > >> > >> > >>........................................................................................................... > >> > >> > >>........................................................................................................... > >> > >> > >>.............................................................found > >>candidate secondary superblock... > >>error reading superblock 54 -- seek to offset 57982058496 failed > >>unable to verify superblock, continuing... > >>........................................................................................................... > >> > >> > >>........................................................................................................... > >> > >> > >>........................................................................................................... > >> > >> > >>........................................................................................................... > >> > >> > >>........................................................................................................... > >> > >> > >>........................................................................................................... > >> > >> > >>........................................................................................................... > >> > >> > >>........................................................................................................... > >> > >> > >>........................................................................................................... > >> > >> > >>.............................................................found > >>candidate secondary superblock... > >>error reading superblock 54 -- seek to offset 57982058496 failed > >>unable to verify superblock, continuing... > >> > >> > >>goes on for ever. > >> > >>here something else that I saw that you requested from somebody who had > >>the same bug: > >> > >>leonzwei root # xfs_db /dev/hdc3 > >>xfs_db: unexpected XFS SB magic number 0x1917d8b3 > >>xfs_db: sb 0 > >>xfs_db: p > >>magicnum = 0x1917d8b3 > >>blocksize = 689553475 > >>dblocks = 12180848741608851668 > >>rblocks = 8457844901802481315 > >>rextents = 17089333805017595916 > >>uuid = c005688d-587d-e4b5-7729-c2cd4e81e350 > >>logstart = 12437974581420056107 > >>rootino = 2035592538136216092 > >>rbmino = 2311019282328682982 > >>rsumino = 940638864488651459 > >>rextsize = 4062341194 > >>agblocks = 1795335310 > >>agcount = 3583083788 > >>rbmblocks = 745776455 > >>logblocks = 2344638215 > >>versionnum = 0xcd77 > >>sectsize = 57419 > >>inodesize = 22122 > >>inopblock = 22912 > >>fname = "q\275\347\017o;\202\376 >>blocklog = 253 > >>sectlog = 155 > >>inodelog = 111 > >>inopblog = 173 > >>agblklog = 91 > >>rextslog = 155 > >>inprogress = 45 > >>imax_pct = 183 > >>icount = 3536497887666359542 > >>ifree = 15647017454152257949 > >>fdblocks = 15766340045555572059 > >>frextents = 7127039695291382717 > >>uquotino = 7880036713507589276 > >>gquotino = 3559299706880429710 > >>qflags = 0x5d07 > >>flags = 0xe9 > >>shared_vn = 152 > >>inoalignmt = 237542219 > >>unit = 2706140452 > >>width = 574901660 > >>dirblklog = 54 > >>logsectlog = 60 > >>logsectsize = 49029 > >>logsunit = 1105637059 > >>xfs_db: > >> > >> > >>anything else I can provide bug hunters with? > >> > >>erik -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Mar 10 09:34:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 09:34:47 -0800 (PST) Received: from mx.leogic.com (mx.leogic.com [62.245.182.8]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2AHYdKO032488 for ; Wed, 10 Mar 2004 09:34:40 -0800 Received: from leogic.com ([192.168.41.28]) (authenticated bits=0) by mx.leogic.com (8.12.11/8.12.10) with ESMTP id i2AHaP82021096 (version=TLSv1/SSLv3 cipher=IDEA-CBC-SHA bits=128 verify=NO); Wed, 10 Mar 2004 18:36:25 +0100 Message-ID: <404F51A4.4010607@leogic.com> Date: Wed, 10 Mar 2004 18:34:28 +0100 From: "Errikos Pitsos {secure}" Organization: leogic User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040126 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Eric Sandeen {unsecure}" CC: "linux-xfs@oss.sgi.com {unsecure}" Subject: Re: ran into rare bug: "unable to verify superblock, continuing..." References: <404ED170.9000601@leogic.com> <1078936989.18173.13.camel@stout.americas.sgi.com> <404F481C.5090801@leogic.com> <1078938738.18173.19.camel@stout.americas.sgi.com> In-Reply-To: <1078938738.18173.19.camel@stout.americas.sgi.com> X-Enigmail-Version: 0.83.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2408 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ep@leogic.com Precedence: bulk X-list: linux-xfs Content-Length: 1437 Lines: 42 Eric Sandeen {u} wrote: > Well, one way or another you got block 0 clobbered... > I'm guessing that perhaps xfs_repair is finding an older superblock from > your previous mkfs, and getting confused. I'd let repair run to This could very well be. Though I let the repair work for 30 mins and nothing of its output changed, always in this loop. > completion and see if it finds other superblocks that are valid... > that's my best suggestion for now. I'll let it run overnight. >>3. So resized 2 and 3, which naturally deleted the data on both of them. > > I hope you re-ran mkfs at this point? yup I had to force it though, as mkfs detected the old xfs partition even though I had stolen the first 2GB from it. >>and put the hd back into the original laptop. She booted fine, grub, >>everything, but during kernel loading isn't able to mount the xfs. >>partition(root) I took the hd out again and tried mounting the hd on the >>system where I had copied the stuff from. Nothing works there either, so >>that's where I am now. > > > I assume that if you repartitioned part3 (root), you probably also > re-ran your bootloader. Again, did you tell the bootloader to land on > the mbr, or on a partition? Nope I didn't run my boot loader again. Grub jumps to the first partition and loads the kernel from there and all that went fine. All I did is rewrite the partition table for partition 2 and 3. cheers, e From owner-linux-xfs@oss.sgi.com Wed Mar 10 11:09:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 11:09:53 -0800 (PST) Received: from atl-ms1.megatrends.com (mail2.megatrends.com [155.229.80.16]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2AJ9kKO005420 for ; Wed, 10 Mar 2004 11:09:46 -0800 Received: by atl-ms1.megatrends.com with Internet Mail Service (5.5.2657.72) id ; Wed, 10 Mar 2004 14:15:03 -0500 Message-ID: <8CCBDD5583C50E4196F012E79439B45C04C9A320@atl-ms1.megatrends.com> From: Vinesh Christopher To: "'linux-xfs@oss.sgi.com'" Subject: Bug : XFS - XSCALE "Directory Not Empty" Date: Wed, 10 Mar 2004 14:14:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Disposition: inline Content-type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 2409 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vineshc@ami.com Precedence: bulk X-list: linux-xfs Content-Length: 2321 Lines: 85 Intel IQ80321 (Xscale) Evaluation Board Running Linux 2.6.0 with -rmk2 patches xfsprogs_2.6.3-1 is taken from debian I did the following # mkfs.xfs /dev/sda1 # mount /dev/sda1 /mnt # cd /mnt # mkdir t # cp /lib/* t # rm -r -f t rm: cannot remove directory 't' : Directory not empty # But the directory is empty. Unmounted the filesystem and ran xfs_repair -n /dev/sda1 which produced the following output : Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 size of entry #0 overflows space left in in shortform dir 131 would junk 2 entries would have corrected entry count in directory 131 from 2 to 0 would have corrected directory 131 size from 30 to 8 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 entry " libwrap.so.0.7" in shortform directory 131 references non-existent inod e 18432 size of entry #0 overflows space left in in shortform dir 131 would junk 2 entries would have corrected entry count in directory 131 from 2 to 0 would have corrected directory 131 size from 30 to 8 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected inode 267, would move to lost+found disconnected inode 268, would move to lost+found Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. I tried with 2.4.21 and XFS 1.3.1 patches -> same problem Anybody seen this? Help!! [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Mar 10 11:28:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 11:28:23 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:IPiq2lyqv3uDsdlaNtgmYDdGMGlFpjwa@12-222-156-122.client.insightBB.com [12.222.156.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2AJS1KO006277 for ; Wed, 10 Mar 2004 11:28:02 -0800 Received: from localhost (burgers.bubbanfriends.org [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 69ED51421005; Wed, 10 Mar 2004 14:30:49 -0500 (EST) Received: from burgers.bubbanfriends.org ([127.0.0.1]) by localhost (burgers.bubbanfriends.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13983-05; Wed, 10 Mar 2004 14:30:47 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 95C271421001; Wed, 10 Mar 2004 14:30:47 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 802C730002A2; Wed, 10 Mar 2004 14:30:47 -0500 (EST) Date: Wed, 10 Mar 2004 14:30:47 -0500 (EST) From: Mike Burger To: Vinesh Christopher Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: Bug : XFS - XSCALE "Directory Not Empty" In-Reply-To: <8CCBDD5583C50E4196F012E79439B45C04C9A320@atl-ms1.megatrends.com> Message-ID: References: <8CCBDD5583C50E4196F012E79439B45C04C9A320@atl-ms1.megatrends.com> MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new at bubbanfriends.org Content-Transfer-Encoding: 8bit X-archive-position: 2410 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 2931 Lines: 108 What happens if you just try "rm -rf t"? On Wed, 10 Mar 2004, Vinesh Christopher wrote: > > Intel IQ80321 (Xscale) Evaluation Board > Running Linux 2.6.0 with -rmk2 patches > xfsprogs_2.6.3-1 is taken from debian > > I did the following > > # mkfs.xfs /dev/sda1 > # mount /dev/sda1 /mnt > # cd /mnt > # mkdir t > # cp /lib/* t > # rm -r -f t > rm: cannot remove directory 't' : Directory not empty > # > > But the directory is empty. Unmounted the filesystem > and ran xfs_repair -n /dev/sda1 which produced the following > output : > > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - scan filesystem freespace and inode maps... > - found root inode chunk > Phase 3 - for each AG... > - scan (but don't clear) agi unlinked lists... > - process known inodes and perform inode discovery... > - agno = 0 > size of entry #0 overflows space left in in shortform dir 131 > would junk 2 entries > would have corrected entry count in directory 131 from 2 to 0 > would have corrected directory 131 size from 30 to 8 > - agno = 1 > - agno = 2 > - agno = 3 > - agno = 4 > - agno = 5 > - agno = 6 > - agno = 7 > - process newly discovered inodes... > Phase 4 - check for duplicate blocks... > - setting up duplicate extent list... > - check for inodes claiming duplicate blocks... > - agno = 0 > entry " libwrap.so.0.7" in shortform directory 131 references non-existent > inod > e 18432 > size of entry #0 overflows space left in in shortform dir 131 > would junk 2 entries > would have corrected entry count in directory 131 from 2 to 0 > would have corrected directory 131 size from 30 to 8 > - agno = 1 > - agno = 2 > - agno = 3 > - agno = 4 > - agno = 5 > - agno = 6 > - agno = 7 > No modify flag set, skipping phase 5 > Phase 6 - check inode connectivity... > - traversing filesystem starting at / ... > - traversal finished ... > - traversing all unattached subtrees ... > - traversals finished ... > - moving disconnected inodes to lost+found ... > disconnected inode 267, would move to lost+found > disconnected inode 268, would move to lost+found > Phase 7 - verify link counts... > No modify flag set, skipping filesystem flush and exiting. > > > > I tried with 2.4.21 and XFS 1.3.1 patches -> same problem > > Anybody seen this? > > > Help!! > > > > > > [[HTML alternate version deleted]] > > -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Wed Mar 10 14:23:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 14:23:28 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2AMNOKO015740 for ; Wed, 10 Mar 2004 14:23:25 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2B0OES0011318 for ; Wed, 10 Mar 2004 16:24:15 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA15199; Thu, 11 Mar 2004 09:23:16 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2AMNCFx212175; Thu, 11 Mar 2004 09:23:12 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i2AMMoPa000887; Thu, 11 Mar 2004 09:22:50 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i2AMMllU000885; Thu, 11 Mar 2004 09:22:47 +1100 Date: Thu, 11 Mar 2004 09:22:47 +1100 From: Nathan Scott To: Jens Axboe Cc: Linux Kernel , kenneth.w.chen@intel.com, Andrew Morton , thornber@redhat.com, linux-xfs@oss.sgi.com Subject: Re: [PATCH] backing dev unplugging Message-ID: <20040310222247.GA713@frodo> References: <20040310124507.GU4949@suse.de> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040310124507.GU4949@suse.de> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2411 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3330 Lines: 113 Hi Jens, On Wed, Mar 10, 2004 at 01:45:07PM +0100, Jens Axboe wrote: > ...[snip]... > diff -ur -X /home/axboe/cdrom/exclude /opt/kernel/linux-2.6.4-rc2-mm1/fs/xfs/linux/xfs_buf.c linux-2.6.4-rc2-mm1-plug/fs/xfs/linux/xfs_buf.c > --- /opt/kernel/linux-2.6.4-rc2-mm1/fs/xfs/linux/xfs_buf.c 2004-03-09 13:08:30.000000000 +0100 > +++ linux-2.6.4-rc2-mm1-plug/fs/xfs/linux/xfs_buf.c 2004-03-10 13:13:49.000000000 +0100 > @@ -1013,7 +1013,7 @@ > { > PB_TRACE(pb, "lock", 0); > if (atomic_read(&pb->pb_io_remaining)) > - blk_run_queues(); > + blk_run_address_space(pb->pb_target->pbr_mapping); > down(&pb->pb_sema); > PB_SET_OWNER(pb); > PB_TRACE(pb, "locked", 0); > @@ -1109,7 +1109,7 @@ > if (atomic_read(&pb->pb_pin_count) == 0) > break; > if (atomic_read(&pb->pb_io_remaining)) > - blk_run_queues(); > + blk_run_address_space(pb->pb_target->pbr_mapping); > schedule(); > } > remove_wait_queue(&pb->pb_waiters, &wait); > @@ -1407,7 +1407,7 @@ > if (pb->pb_flags & PBF_RUN_QUEUES) { > pb->pb_flags &= ~PBF_RUN_QUEUES; > if (atomic_read(&pb->pb_io_remaining) > 1) > - blk_run_queues(); > + blk_run_address_space(pb->pb_target->pbr_mapping); > } > } > > @@ -1471,7 +1471,7 @@ > { > PB_TRACE(pb, "iowait", 0); > if (atomic_read(&pb->pb_io_remaining)) > - blk_run_queues(); > + blk_run_address_space(pb->pb_target->pbr_mapping); > down(&pb->pb_iodonesema); > PB_TRACE(pb, "iowaited", (long)pb->pb_error); > return pb->pb_error; > @@ -1617,7 +1617,6 @@ > pagebuf_daemon( > void *data) > { > - int count; > page_buf_t *pb; > struct list_head *curr, *next, tmp; > > @@ -1640,7 +1639,6 @@ > > spin_lock(&pbd_delwrite_lock); > > - count = 0; > list_for_each_safe(curr, next, &pbd_delwrite_queue) { > pb = list_entry(curr, page_buf_t, pb_list); > > @@ -1657,7 +1655,7 @@ > pb->pb_flags &= ~PBF_DELWRI; > pb->pb_flags |= PBF_WRITE; > list_move(&pb->pb_list, &tmp); > - count++; > + blk_run_address_space(pb->pb_target->pbr_mapping); > } This moves the blk_run_address_space to before we submit the I/O (this bit of code is moving buffers off the delwri queue onto a temporary queue, buffers on the temporary queue are then submitted a little further down) - I suspect we need to move this new blk_run_address_space call down into the temp list processing, just after pagebuf_iostrategy. > } > > @@ -1671,8 +1669,6 @@ > > if (as_list_len > 0) > purge_addresses(); > - if (count) > - blk_run_queues(); > > force_flush = 0; > } while (pagebuf_daemon_active); > @@ -1734,13 +1730,11 @@ > pagebuf_lock(pb); > pagebuf_iostrategy(pb); > if (++flush_cnt > 32) { > - blk_run_queues(); > + blk_run_address_space(pb->pb_target->pbr_mapping); > flush_cnt = 0; > } > } > > - blk_run_queues(); > - > while (!list_empty(&tmp)) { > pb = list_entry(tmp.next, page_buf_t, pb_list); > For this second one, we probably just want to ditch the flush_cnt there (this change is doing blk_run_address_space on every 32nd buffer target, and not the intervening ones). We will be doing a bunch more blk_run_address_space calls than we probably need to, not sure if thats going to become an issue or not, let me prod some of the other XFS folks for more insight there... thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Mar 10 15:29:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 15:29:04 -0800 (PST) Received: from omr2.verisignmail.com (omr2.verisignmail.com [216.168.230.163]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2ANT0KO018098 for ; Wed, 10 Mar 2004 15:29:01 -0800 Received: from ms8.verisignmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.verisignmail.com (8.12.10/8.12.10) with ESMTP id i2ANOnfY026381 for ; Wed, 10 Mar 2004 18:24:50 -0500 (EST) Received: from ms8.verisignmail.com (localhost.verisignmail.com [127.0.0.1]) by ms8.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ASZ70436; Wed, 10 Mar 2004 18:28:58 -0500 (EST) From: Message-Id: <200403102328.ASZ70436@ms8.verisignmail.com> Received: from 65.104.102.243 by ms8.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with HTTP/1.1; Wed, 10 Mar 2004 18:28:58 -0500 Date: Wed, 10 Mar 2004 18:28:58 -0500 Subject: determining external log size To: linux-xfs@oss.sgi.com X-Mailer: Webmail Mirapoint Direct 3.2.2-GA MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2412 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian@krusic.com Precedence: bulk X-list: linux-xfs Content-Length: 390 Lines: 18 Hi, I couldn't find info on how to best determine external log size so I based it on what the internal log size is of the same partition and re did it with the external log being the same. How does log size effect performance? I'm dealing with 800GB-1.5TB partitions. Is there a sort of performance tweakers faq out there? Bri- Krusic Consulting Inc. Network Consulting Services. From owner-linux-xfs@oss.sgi.com Wed Mar 10 15:36:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 15:36:32 -0800 (PST) Received: from localhost.localdomain (outgoingmail.adic.com [63.81.117.28]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2ANa9KO018676 for ; Wed, 10 Mar 2004 15:36:29 -0800 Received: from xfs.org (jen [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i2ANW6To024546; Wed, 10 Mar 2004 17:32:07 -0600 Message-ID: <404FA575.1090907@xfs.org> Date: Wed, 10 Mar 2004 17:32:05 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: Jens Axboe , Linux Kernel , kenneth.w.chen@intel.com, Andrew Morton , thornber@redhat.com, linux-xfs@oss.sgi.com Subject: Re: [PATCH] backing dev unplugging References: <20040310124507.GU4949@suse.de> <20040310222247.GA713@frodo> In-Reply-To: <20040310222247.GA713@frodo> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2413 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1152 Lines: 28 Nathan Scott wrote: > > For this second one, we probably just want to ditch the flush_cnt > there (this change is doing blk_run_address_space on every 32nd > buffer target, and not the intervening ones). We will be doing a > bunch more blk_run_address_space calls than we probably need to, > not sure if thats going to become an issue or not, let me prod > some of the other XFS folks for more insight there... > > thanks. > The concept there was that we were just pushing things down into the elevator in a batch, then unplugging it afterwards. The do it every 32 I/O's was added to avoid some request starvation issues - which are probably historical now. I was lazy and did not look at the context on the code, but there are two paths in here. One is unmount flushing all the entries for a specific filesystem, the other is background flushing. I think the background flush activity can live without the blk_run_address_space call being there at all. If we need to grab the lock on the metadata later we will make the call then. The unmount case needs to call it, but since that specifies a specific target, it can just make one call. Steve From owner-linux-xfs@oss.sgi.com Wed Mar 10 15:38:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 15:38:30 -0800 (PST) Received: from shksmtp01.so-net.com.hk (pop3.so-net.com.hk [203.99.142.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2ANcQKO019144 for ; Wed, 10 Mar 2004 15:38:27 -0800 Received: (qmail 14004 invoked from network); 10 Mar 2004 23:38:16 -0000 Received: from so165248.bbo165.so-net.com.hk (HELO linuxmail.org) ([203.176.165.248]) (envelope-sender ) by shksmtp01.so-net.com.hk (qmail-ldap-1.03) with SMTP for ; 10 Mar 2004 23:38:16 -0000 Message-ID: <404FA6E8.4000608@linuxmail.org> Date: Thu, 11 Mar 2004 07:38:16 +0800 From: Feizhou User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: XFS Mailing List Subject: Re: mkfs under different kernels References: <404F1F68.30700@linuxmail.org> <404F2546.90904@linuxmail.org> <1078936304.18173.4.camel@stout.americas.sgi.com> In-Reply-To: <1078936304.18173.4.camel@stout.americas.sgi.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2414 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: feizhou@linuxmail.org Precedence: bulk X-list: linux-xfs Content-Length: 372 Lines: 13 Eric Sandeen wrote: > mkfs does query the kernel for device size, stripe info, etc. > So if 2.4 returns a different answer than 2.6, that's the only > difference I can see that might matter. > > But the short answer is that it should not make a difference. > > You can do a quick test; if the mkfs.xfs output does not change, then > there is no difference. > Thanks. From owner-linux-xfs@oss.sgi.com Wed Mar 10 16:58:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 16:58:54 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:krsyGbvW9LwiMOSfSAjdYC74atL9dzHG@12-222-156-122.client.insightBB.com [12.222.156.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2B0wlKO024751 for ; Wed, 10 Mar 2004 16:58:48 -0800 Received: from localhost (burgers.bubbanfriends.org [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 5752E1421005; Wed, 10 Mar 2004 20:01:37 -0500 (EST) Received: from burgers.bubbanfriends.org ([127.0.0.1]) by localhost (burgers.bubbanfriends.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21266-01; Wed, 10 Mar 2004 20:01:35 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id E0DAF1421001; Wed, 10 Mar 2004 20:01:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id DEB4E30002A2; Wed, 10 Mar 2004 20:01:35 -0500 (EST) Date: Wed, 10 Mar 2004 20:01:35 -0500 (EST) From: Mike Burger To: Vinesh Christopher Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: Bug : XFS - XSCALE "Directory Not Empty" In-Reply-To: <8CCBDD5583C50E4196F012E79439B45C04C9A322@atl-ms1.megatrends.com> Message-ID: References: <8CCBDD5583C50E4196F012E79439B45C04C9A322@atl-ms1.megatrends.com> MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new at bubbanfriends.org Content-Transfer-Encoding: 8bit X-archive-position: 2415 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 3622 Lines: 127 What does ls -al t show you? On Wed, 10 Mar 2004, Vinesh Christopher wrote: > Same result => rm: cannot remove directory 't' : Directory not empty > But all the files are deleted and the directory is empty > I tried rmdir t . It says Directory not empty > > > -----Original Message----- > From: Mike Burger [mailto:mburger@bubbanfriends.org] > Sent: Wednesday, March 10, 2004 2:31 PM > To: Vinesh Christopher > Cc: 'linux-xfs@oss.sgi.com' > Subject: Re: Bug : XFS - XSCALE "Directory Not Empty" > > What happens if you just try "rm -rf t"? > > On Wed, 10 Mar 2004, Vinesh Christopher wrote: > > > > > Intel IQ80321 (Xscale) Evaluation Board > > Running Linux 2.6.0 with -rmk2 patches > > xfsprogs_2.6.3-1 is taken from debian > > > > I did the following > > > > # mkfs.xfs /dev/sda1 > > # mount /dev/sda1 /mnt > > # cd /mnt > > # mkdir t > > # cp /lib/* t > > # rm -r -f t > > rm: cannot remove directory 't' : Directory not empty > > # > > > > But the directory is empty. Unmounted the filesystem > > and ran xfs_repair -n /dev/sda1 which produced the following > > output : > > > > Phase 1 - find and verify superblock... > > Phase 2 - using internal log > > - scan filesystem freespace and inode maps... > > - found root inode chunk > > Phase 3 - for each AG... > > - scan (but don't clear) agi unlinked lists... > > - process known inodes and perform inode discovery... > > - agno = 0 > > size of entry #0 overflows space left in in shortform dir 131 > > would junk 2 entries > > would have corrected entry count in directory 131 from 2 to 0 > > would have corrected directory 131 size from 30 to 8 > > - agno = 1 > > - agno = 2 > > - agno = 3 > > - agno = 4 > > - agno = 5 > > - agno = 6 > > - agno = 7 > > - process newly discovered inodes... > > Phase 4 - check for duplicate blocks... > > - setting up duplicate extent list... > > - check for inodes claiming duplicate blocks... > > - agno = 0 > > entry " libwrap.so.0.7" in shortform directory 131 references > non-existent > > inod > > e 18432 > > size of entry #0 overflows space left in in shortform dir 131 > > would junk 2 entries > > would have corrected entry count in directory 131 from 2 to 0 > > would have corrected directory 131 size from 30 to 8 > > - agno = 1 > > - agno = 2 > > - agno = 3 > > - agno = 4 > > - agno = 5 > > - agno = 6 > > - agno = 7 > > No modify flag set, skipping phase 5 > > Phase 6 - check inode connectivity... > > - traversing filesystem starting at / ... > > - traversal finished ... > > - traversing all unattached subtrees ... > > - traversals finished ... > > - moving disconnected inodes to lost+found ... > > disconnected inode 267, would move to lost+found > > disconnected inode 268, would move to lost+found > > Phase 7 - verify link counts... > > No modify flag set, skipping filesystem flush and exiting. > > > > > > > > I tried with 2.4.21 and XFS 1.3.1 patches -> same problem > > > > Anybody seen this? > > > > > > Help!! > > > > > > > > > > > > [[HTML alternate version deleted]] > > > > > > -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Wed Mar 10 17:11:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 17:11:29 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2B1BQKO025433 for ; Wed, 10 Mar 2004 17:11:27 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2B1BK02012072 for ; Wed, 10 Mar 2004 17:11:21 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA17742; Thu, 11 Mar 2004 12:11:18 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2B1BGFx216148; Thu, 11 Mar 2004 12:11:16 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i2B1AtPa001431; Thu, 11 Mar 2004 12:10:55 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i2B1AsGX001429; Thu, 11 Mar 2004 12:10:54 +1100 Date: Thu, 11 Mar 2004 12:10:54 +1100 From: Nathan Scott To: Vinesh Christopher Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: Bug : XFS - XSCALE "Directory Not Empty" Message-ID: <20040311011054.GA1389@frodo> References: <8CCBDD5583C50E4196F012E79439B45C04C9A320@atl-ms1.megatrends.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8CCBDD5583C50E4196F012E79439B45C04C9A320@atl-ms1.megatrends.com> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2416 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 731 Lines: 32 On Wed, Mar 10, 2004 at 02:14:58PM -0500, Vinesh Christopher wrote: > > Intel IQ80321 (Xscale) Evaluation Board > Running Linux 2.6.0 with -rmk2 patches > xfsprogs_2.6.3-1 is taken from debian > > I did the following > > # mkfs.xfs /dev/sda1 > # mount /dev/sda1 /mnt > # cd /mnt > # mkdir t > # cp /lib/* t > # rm -r -f t > rm: cannot remove directory 't' : Directory not empty > # Any errors on your console or in your system logs? I tried this locally and (not really surprisingly) it works just fine on my system. > I tried with 2.4.21 and XFS 1.3.1 patches -> same problem Uhrm, odd - there are lots of people using XFS from that kernel. I'm inclined to suspect your hardware at this stage. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Mar 10 21:41:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 21:41:47 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2B5fgKO015682 for ; Wed, 10 Mar 2004 21:41:42 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2B5ST02003180 for ; Wed, 10 Mar 2004 21:28:30 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2B5STKe35221835; Wed, 10 Mar 2004 23:28:29 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i2B5SSEr1821263; Wed, 10 Mar 2004 23:28:29 -0600 (CST) Date: Wed, 10 Mar 2004 23:28:28 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Vinesh Christopher cc: "'linux-xfs@oss.sgi.com'" Subject: Re: Bug : XFS - XSCALE "Directory Not Empty" In-Reply-To: <8CCBDD5583C50E4196F012E79439B45C04C9A320@atl-ms1.megatrends.com> Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2417 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 266 Lines: 11 On Wed, 10 Mar 2004, Vinesh Christopher wrote: > I tried with 2.4.21 and XFS 1.3.1 patches -> same problem this is from a fresh mkfs too? First thing i'd try is another device, I think, to start ruling out hardware. rm -rf has always worked for me... :) -Eric From owner-linux-xfs@oss.sgi.com Wed Mar 10 23:05:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Mar 2004 23:06:04 -0800 (PST) Received: from virtualhost.dk (ns.virtualhost.dk [195.184.98.160]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2B75mKO019249 for ; Wed, 10 Mar 2004 23:05:49 -0800 Received: from [62.242.22.158] (helo=wiggum.home.kernel.dk) by virtualhost.dk with esmtp (Exim 3.36 #1) id 1B1KFz-0002vW-00; Thu, 11 Mar 2004 08:05:27 +0100 Received: from axboe by wiggum.home.kernel.dk with local (Exim 4.22) id 1B1KFy-0001rX-6A; Thu, 11 Mar 2004 08:05:26 +0100 Date: Thu, 11 Mar 2004 08:05:26 +0100 From: Jens Axboe To: Nathan Scott Cc: Linux Kernel , kenneth.w.chen@intel.com, Andrew Morton , thornber@redhat.com, linux-xfs@oss.sgi.com Subject: Re: [PATCH] backing dev unplugging Message-ID: <20040311070526.GD6955@suse.de> References: <20040310124507.GU4949@suse.de> <20040310222247.GA713@frodo> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040310222247.GA713@frodo> Content-Transfer-Encoding: 8bit X-archive-position: 2418 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: axboe@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 3793 Lines: 120 On Thu, Mar 11 2004, Nathan Scott wrote: > Hi Jens, > > On Wed, Mar 10, 2004 at 01:45:07PM +0100, Jens Axboe wrote: > > ...[snip]... > > diff -ur -X /home/axboe/cdrom/exclude /opt/kernel/linux-2.6.4-rc2-mm1/fs/xfs/linux/xfs_buf.c linux-2.6.4-rc2-mm1-plug/fs/xfs/linux/xfs_buf.c > > --- /opt/kernel/linux-2.6.4-rc2-mm1/fs/xfs/linux/xfs_buf.c 2004-03-09 13:08:30.000000000 +0100 > > +++ linux-2.6.4-rc2-mm1-plug/fs/xfs/linux/xfs_buf.c 2004-03-10 13:13:49.000000000 +0100 > > @@ -1013,7 +1013,7 @@ > > { > > PB_TRACE(pb, "lock", 0); > > if (atomic_read(&pb->pb_io_remaining)) > > - blk_run_queues(); > > + blk_run_address_space(pb->pb_target->pbr_mapping); > > down(&pb->pb_sema); > > PB_SET_OWNER(pb); > > PB_TRACE(pb, "locked", 0); > > @@ -1109,7 +1109,7 @@ > > if (atomic_read(&pb->pb_pin_count) == 0) > > break; > > if (atomic_read(&pb->pb_io_remaining)) > > - blk_run_queues(); > > + blk_run_address_space(pb->pb_target->pbr_mapping); > > schedule(); > > } > > remove_wait_queue(&pb->pb_waiters, &wait); > > @@ -1407,7 +1407,7 @@ > > if (pb->pb_flags & PBF_RUN_QUEUES) { > > pb->pb_flags &= ~PBF_RUN_QUEUES; > > if (atomic_read(&pb->pb_io_remaining) > 1) > > - blk_run_queues(); > > + blk_run_address_space(pb->pb_target->pbr_mapping); > > } > > } > > > > @@ -1471,7 +1471,7 @@ > > { > > PB_TRACE(pb, "iowait", 0); > > if (atomic_read(&pb->pb_io_remaining)) > > - blk_run_queues(); > > + blk_run_address_space(pb->pb_target->pbr_mapping); > > down(&pb->pb_iodonesema); > > PB_TRACE(pb, "iowaited", (long)pb->pb_error); > > return pb->pb_error; > > @@ -1617,7 +1617,6 @@ > > pagebuf_daemon( > > void *data) > > { > > - int count; > > page_buf_t *pb; > > struct list_head *curr, *next, tmp; > > > > @@ -1640,7 +1639,6 @@ > > > > spin_lock(&pbd_delwrite_lock); > > > > - count = 0; > > list_for_each_safe(curr, next, &pbd_delwrite_queue) { > > pb = list_entry(curr, page_buf_t, pb_list); > > > > @@ -1657,7 +1655,7 @@ > > pb->pb_flags &= ~PBF_DELWRI; > > pb->pb_flags |= PBF_WRITE; > > list_move(&pb->pb_list, &tmp); > > - count++; > > + blk_run_address_space(pb->pb_target->pbr_mapping); > > } > > This moves the blk_run_address_space to before we submit the > I/O (this bit of code is moving buffers off the delwri queue > onto a temporary queue, buffers on the temporary queue are > then submitted a little further down) - I suspect we need to > move this new blk_run_address_space call down into the temp > list processing, just after pagebuf_iostrategy. I'm not surprised, the XFS 'conversion' was done quickly and is expected to be half-assed :) Thanks a lot for taking a look at this. > > } > > > > @@ -1671,8 +1669,6 @@ > > > > if (as_list_len > 0) > > purge_addresses(); > > - if (count) > > - blk_run_queues(); > > > > force_flush = 0; > > } while (pagebuf_daemon_active); > > @@ -1734,13 +1730,11 @@ > > pagebuf_lock(pb); > > pagebuf_iostrategy(pb); > > if (++flush_cnt > 32) { > > - blk_run_queues(); > > + blk_run_address_space(pb->pb_target->pbr_mapping); > > flush_cnt = 0; > > } > > } > > > > - blk_run_queues(); > > - > > while (!list_empty(&tmp)) { > > pb = list_entry(tmp.next, page_buf_t, pb_list); > > > > For this second one, we probably just want to ditch the flush_cnt > there (this change is doing blk_run_address_space on every 32nd > buffer target, and not the intervening ones). We will be doing a > bunch more blk_run_address_space calls than we probably need to, > not sure if thats going to become an issue or not, let me prod > some of the other XFS folks for more insight there... If any of you could send me a replacement xfs_buf bit, I'd much appreciate it. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Thu Mar 11 07:36:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Mar 2004 07:36:29 -0800 (PST) Received: from atl-ms1.megatrends.com (mail2.megatrends.com [155.229.80.16]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2BFaMKO008485 for ; Thu, 11 Mar 2004 07:36:23 -0800 Received: by atl-ms1.megatrends.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Mar 2004 10:38:37 -0500 Message-ID: <8CCBDD5583C50E4196F012E79439B45C04C9A32B@atl-ms1.megatrends.com> From: Vinesh Christopher To: "'Mike Burger'" Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: Bug : XFS - XSCALE "Directory Not Empty" Date: Thu, 11 Mar 2004 10:38:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 2419 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vineshc@ami.com Precedence: bulk X-list: linux-xfs Content-Length: 3880 Lines: 136 Just two entries "." and ".." -----Original Message----- From: Mike Burger [mailto:mburger@bubbanfriends.org] Sent: Wednesday, March 10, 2004 8:02 PM To: Vinesh Christopher Cc: 'linux-xfs@oss.sgi.com' Subject: RE: Bug : XFS - XSCALE "Directory Not Empty" What does ls -al t show you? On Wed, 10 Mar 2004, Vinesh Christopher wrote: > Same result => rm: cannot remove directory 't' : Directory not empty > But all the files are deleted and the directory is empty > I tried rmdir t . It says Directory not empty > > > -----Original Message----- > From: Mike Burger [mailto:mburger@bubbanfriends.org] > Sent: Wednesday, March 10, 2004 2:31 PM > To: Vinesh Christopher > Cc: 'linux-xfs@oss.sgi.com' > Subject: Re: Bug : XFS - XSCALE "Directory Not Empty" > > What happens if you just try "rm -rf t"? > > On Wed, 10 Mar 2004, Vinesh Christopher wrote: > > > > > Intel IQ80321 (Xscale) Evaluation Board > > Running Linux 2.6.0 with -rmk2 patches > > xfsprogs_2.6.3-1 is taken from debian > > > > I did the following > > > > # mkfs.xfs /dev/sda1 > > # mount /dev/sda1 /mnt > > # cd /mnt > > # mkdir t > > # cp /lib/* t > > # rm -r -f t > > rm: cannot remove directory 't' : Directory not empty > > # > > > > But the directory is empty. Unmounted the filesystem > > and ran xfs_repair -n /dev/sda1 which produced the following > > output : > > > > Phase 1 - find and verify superblock... > > Phase 2 - using internal log > > - scan filesystem freespace and inode maps... > > - found root inode chunk > > Phase 3 - for each AG... > > - scan (but don't clear) agi unlinked lists... > > - process known inodes and perform inode discovery... > > - agno = 0 > > size of entry #0 overflows space left in in shortform dir 131 > > would junk 2 entries > > would have corrected entry count in directory 131 from 2 to 0 > > would have corrected directory 131 size from 30 to 8 > > - agno = 1 > > - agno = 2 > > - agno = 3 > > - agno = 4 > > - agno = 5 > > - agno = 6 > > - agno = 7 > > - process newly discovered inodes... > > Phase 4 - check for duplicate blocks... > > - setting up duplicate extent list... > > - check for inodes claiming duplicate blocks... > > - agno = 0 > > entry " libwrap.so.0.7" in shortform directory 131 references > non-existent > > inod > > e 18432 > > size of entry #0 overflows space left in in shortform dir 131 > > would junk 2 entries > > would have corrected entry count in directory 131 from 2 to 0 > > would have corrected directory 131 size from 30 to 8 > > - agno = 1 > > - agno = 2 > > - agno = 3 > > - agno = 4 > > - agno = 5 > > - agno = 6 > > - agno = 7 > > No modify flag set, skipping phase 5 > > Phase 6 - check inode connectivity... > > - traversing filesystem starting at / ... > > - traversal finished ... > > - traversing all unattached subtrees ... > > - traversals finished ... > > - moving disconnected inodes to lost+found ... > > disconnected inode 267, would move to lost+found > > disconnected inode 268, would move to lost+found > > Phase 7 - verify link counts... > > No modify flag set, skipping filesystem flush and exiting. > > > > > > > > I tried with 2.4.21 and XFS 1.3.1 patches -> same problem > > > > Anybody seen this? > > > > > > Help!! > > > > > > > > > > > > [[HTML alternate version deleted]] > > > > > > -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Thu Mar 11 07:58:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Mar 2004 07:58:42 -0800 (PST) Received: from atl-ms1.megatrends.com (mail2.megatrends.com [155.229.80.16]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2BFwYKO009240 for ; Thu, 11 Mar 2004 07:58:35 -0800 Received: by atl-ms1.megatrends.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Mar 2004 10:42:51 -0500 Message-ID: <8CCBDD5583C50E4196F012E79439B45C04C9A32D@atl-ms1.megatrends.com> From: Vinesh Christopher To: "'Eric Sandeen'" Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: Bug : XFS - XSCALE "Directory Not Empty" Date: Thu, 11 Mar 2004 10:42:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 2420 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vineshc@ami.com Precedence: bulk X-list: linux-xfs Content-Length: 723 Lines: 29 Yes, From a fresh mkfs. It works for me on x86 platforms. I tried it on two Xscale board, each with IDE and SCSI disks, and it is the same problem. In the same setup, I used ext3, it works fine. This eliminates the hardware issues. -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: Thursday, March 11, 2004 12:28 AM To: Vinesh Christopher Cc: 'linux-xfs@oss.sgi.com' Subject: Re: Bug : XFS - XSCALE "Directory Not Empty" On Wed, 10 Mar 2004, Vinesh Christopher wrote: > I tried with 2.4.21 and XFS 1.3.1 patches -> same problem this is from a fresh mkfs too? First thing i'd try is another device, I think, to start ruling out hardware. rm -rf has always worked for me... :) -Eric From owner-linux-xfs@oss.sgi.com Thu Mar 11 09:00:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Mar 2004 09:00:14 -0800 (PST) Received: from atl-ms1.megatrends.com (mail2.megatrends.com [155.229.80.16]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2BH07KO015854 for ; Thu, 11 Mar 2004 09:00:08 -0800 Received: by atl-ms1.megatrends.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Mar 2004 10:39:47 -0500 Message-ID: <8CCBDD5583C50E4196F012E79439B45C04C9A32C@atl-ms1.megatrends.com> From: Vinesh Christopher To: "'Nathan Scott'" , Vinesh Christopher Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: Bug : XFS - XSCALE "Directory Not Empty" Date: Thu, 11 Mar 2004 10:39:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 2421 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vineshc@ami.com Precedence: bulk X-list: linux-xfs Content-Length: 1023 Lines: 42 It works on x86 platforms for me. The problem is With the XSCALE board. -----Original Message----- From: Nathan Scott [mailto:nathans@sgi.com] Sent: Wednesday, March 10, 2004 8:11 PM To: Vinesh Christopher Cc: 'linux-xfs@oss.sgi.com' Subject: Re: Bug : XFS - XSCALE "Directory Not Empty" On Wed, Mar 10, 2004 at 02:14:58PM -0500, Vinesh Christopher wrote: > > Intel IQ80321 (Xscale) Evaluation Board > Running Linux 2.6.0 with -rmk2 patches > xfsprogs_2.6.3-1 is taken from debian > > I did the following > > # mkfs.xfs /dev/sda1 > # mount /dev/sda1 /mnt > # cd /mnt > # mkdir t > # cp /lib/* t > # rm -r -f t > rm: cannot remove directory 't' : Directory not empty > # Any errors on your console or in your system logs? I tried this locally and (not really surprisingly) it works just fine on my system. > I tried with 2.4.21 and XFS 1.3.1 patches -> same problem Uhrm, odd - there are lots of people using XFS from that kernel. I'm inclined to suspect your hardware at this stage. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Mar 11 09:36:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Mar 2004 09:37:00 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2BHasKO016799 for ; Thu, 11 Mar 2004 09:36:54 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2BJbqel001017 for ; Thu, 11 Mar 2004 11:37:52 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2BHajKe35219153; Thu, 11 Mar 2004 11:36:45 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i2BHaiEq1868046; Thu, 11 Mar 2004 11:36:44 -0600 (CST) Subject: RE: Bug : XFS - XSCALE "Directory Not Empty" From: Eric Sandeen To: Vinesh Christopher Cc: "'Nathan Scott'" , "'linux-xfs@oss.sgi.com'" In-Reply-To: <8CCBDD5583C50E4196F012E79439B45C04C9A32C@atl-ms1.megatrends.com> References: <8CCBDD5583C50E4196F012E79439B45C04C9A32C@atl-ms1.megatrends.com> Content-type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1079026604.21977.21.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 11 Mar 2004 11:36:44 -0600 Content-Transfer-Encoding: 8bit X-archive-position: 2422 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1718 Lines: 58 Ok, I don't know the details of the xscale platform; apparently xfs needs some fixes. Sorry, I was only recently filled in on some of the details of xscale... XFS has not had any testing on this sort of hardware at SGI... This is probably going to be difficult to debug without access to the hardware. Is anyone else on the list using XFS successfully with ARM-type hardware? For starters - did you use a gnu toolchain to build the kernel? -Eric On Thu, 2004-03-11 at 09:39, Vinesh Christopher wrote: > It works on x86 platforms for me. The problem is > With the XSCALE board. > > -----Original Message----- > From: Nathan Scott [mailto:nathans@sgi.com] > Sent: Wednesday, March 10, 2004 8:11 PM > To: Vinesh Christopher > Cc: 'linux-xfs@oss.sgi.com' > Subject: Re: Bug : XFS - XSCALE "Directory Not Empty" > > On Wed, Mar 10, 2004 at 02:14:58PM -0500, Vinesh Christopher wrote: > > > > Intel IQ80321 (Xscale) Evaluation Board > > Running Linux 2.6.0 with -rmk2 patches > > xfsprogs_2.6.3-1 is taken from debian > > > > I did the following > > > > # mkfs.xfs /dev/sda1 > > # mount /dev/sda1 /mnt > > # cd /mnt > > # mkdir t > > # cp /lib/* t > > # rm -r -f t > > rm: cannot remove directory 't' : Directory not empty > > # > > Any errors on your console or in your system logs? > > I tried this locally and (not really surprisingly) it works > just fine on my system. > > > I tried with 2.4.21 and XFS 1.3.1 patches -> same problem > > Uhrm, odd - there are lots of people using XFS from that kernel. > I'm inclined to suspect your hardware at this stage. > > cheers. -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Mar 11 09:39:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Mar 2004 09:39:58 -0800 (PST) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2BHdpKO017186 for ; Thu, 11 Mar 2004 09:39:51 -0800 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2BHfleS029162; Thu, 11 Mar 2004 17:41:47 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2BHf2xf009982; Thu, 11 Mar 2004 17:41:30 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031109393705195 ; Thu, 11 Mar 2004 09:39:37 -0800 Received: from orsmsx405.amr.corp.intel.com ([192.168.65.46]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Mar 2004 09:39:37 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: Bug : XFS - XSCALE "Directory Not Empty" Date: Thu, 11 Mar 2004 09:39:37 -0800 Message-ID: <802FECEADA78854F8DD69950B138D8C9025ABB03@orsmsx405.jf.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bug : XFS - XSCALE "Directory Not Empty" Thread-Index: AcQHiln/SJatLuo9TMC2xGIK/nw2LAAA7s8A From: "Ranslam, Robert E" To: "Vinesh Christopher" , "Nathan Scott" Cc: X-OriginalArrivalTime: 11 Mar 2004 17:39:37.0378 (UTC) FILETIME=[D2EE8020:01C4078F] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i2BHdpKO017187 X-archive-position: 2423 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robert.e.ranslam@intel.com Precedence: bulk X-list: linux-xfs Content-Length: 1869 Lines: 69 FYI: Its also in the IXDP425 as well as the IQ80321. These are two completely different boards the only thing in common really is the Xscale core. Greg Ungerer posted a patch that I echoed. One problem is that is appears to be and issue with a calculation. The comment seems to indicate that the variable used should be 'namelen' but instead is 'count' One thing to consider here - the x86 is Little endian. We are BE on the IXP425 RR > -----Original Message----- > From: linux-xfs-bounce@oss.sgi.com > [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Vinesh Christopher > Sent: Thursday, March 11, 2004 7:40 AM > To: 'Nathan Scott'; Vinesh Christopher > Cc: 'linux-xfs@oss.sgi.com' > Subject: RE: Bug : XFS - XSCALE "Directory Not Empty" > > > It works on x86 platforms for me. The problem is > With the XSCALE board. > > -----Original Message----- > From: Nathan Scott [mailto:nathans@sgi.com] > Sent: Wednesday, March 10, 2004 8:11 PM > To: Vinesh Christopher > Cc: 'linux-xfs@oss.sgi.com' > Subject: Re: Bug : XFS - XSCALE "Directory Not Empty" > > On Wed, Mar 10, 2004 at 02:14:58PM -0500, Vinesh Christopher wrote: > > > > Intel IQ80321 (Xscale) Evaluation Board > > Running Linux 2.6.0 with -rmk2 patches > > xfsprogs_2.6.3-1 is taken from debian > > > > I did the following > > > > # mkfs.xfs /dev/sda1 > > # mount /dev/sda1 /mnt > > # cd /mnt > > # mkdir t > > # cp /lib/* t > > # rm -r -f t > > rm: cannot remove directory 't' : Directory not empty > > # > > Any errors on your console or in your system logs? > > I tried this locally and (not really surprisingly) it works > just fine on my system. > > > I tried with 2.4.21 and XFS 1.3.1 patches -> same problem > > Uhrm, odd - there are lots of people using XFS from that kernel. > I'm inclined to suspect your hardware at this stage. > > cheers. > > -- > Nathan > > > From owner-linux-xfs@oss.sgi.com Thu Mar 11 10:14:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Mar 2004 10:14:38 -0800 (PST) Received: from localhost.localdomain (outgoingmail.adic.com [63.81.117.28]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2BIEUKO017967 for ; Thu, 11 Mar 2004 10:14:30 -0800 Received: from xfs.org (jen [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i2BI91To004376; Thu, 11 Mar 2004 12:09:02 -0600 Message-ID: <4050AB3D.9010503@xfs.org> Date: Thu, 11 Mar 2004 12:09:01 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ranslam, Robert E" CC: Vinesh Christopher , Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: Bug : XFS - XSCALE "Directory Not Empty" References: <802FECEADA78854F8DD69950B138D8C9025ABB03@orsmsx405.jf.intel.com> In-Reply-To: <802FECEADA78854F8DD69950B138D8C9025ABB03@orsmsx405.jf.intel.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2424 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 870 Lines: 27 Ranslam, Robert E wrote: > FYI: > Its also in the IXDP425 as well as the IQ80321. These are two > completely different boards the only thing in common really is the > Xscale core. > > Greg Ungerer posted a patch that I echoed. One problem is that is > appears to be and issue with a calculation. The comment seems to > indicate that the variable used should be 'namelen' but instead is > 'count' What patch? please forward it here. > > One thing to consider here - the x86 is Little endian. We are BE on the > IXP425 > XFS runs fine on big endian hardware, that is where it was developed. This is more likely to be a problem in the gcc code generation on the xscale. It would not be the first time that xfs has pushed gcc over the edge. There is a lot of 64 bit stuff inside xfs, and we have seen gcc get very confused about what is in which register. Steve From owner-linux-xfs@oss.sgi.com Thu Mar 11 10:16:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Mar 2004 10:16:50 -0800 (PST) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2BIGhKO018363 for ; Thu, 11 Mar 2004 10:16:43 -0800 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2BIIheS021884; Thu, 11 Mar 2004 18:18:43 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2BIAZPJ030862; Thu, 11 Mar 2004 18:10:38 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031110163311463 ; Thu, 11 Mar 2004 10:16:33 -0800 Received: from orsmsx405.amr.corp.intel.com ([192.168.65.46]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Mar 2004 10:16:33 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-type: text/plain X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: Bug : XFS - XSCALE "Directory Not Empty" Date: Thu, 11 Mar 2004 10:16:32 -0800 Message-ID: <802FECEADA78854F8DD69950B138D8C9025ABBAD@orsmsx405.jf.intel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Bug : XFS - XSCALE "Directory Not Empty" Thread-Index: AcQHlLMpUaz2PZjWQpCIwAX69Wk0VQAAB/ag From: "Ranslam, Robert E" To: "Steve Lord" Cc: "Vinesh Christopher" , "Nathan Scott" , X-OriginalArrivalTime: 11 Mar 2004 18:16:33.0413 (UTC) FILETIME=[FBCA9B50:01C40794] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-archive-position: 2425 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robert.e.ranslam@intel.com Precedence: bulk X-list: linux-xfs Content-Length: 4626 Lines: 127 Attached... again > -----Original Message----- > From: Steve Lord [mailto:lord@xfs.org] > Sent: Thursday, March 11, 2004 10:09 AM > To: Ranslam, Robert E > Cc: Vinesh Christopher; Nathan Scott; linux-xfs@oss.sgi.com > Subject: Re: Bug : XFS - XSCALE "Directory Not Empty" > > > Ranslam, Robert E wrote: > > FYI: > > Its also in the IXDP425 as well as the IQ80321. These are two > > completely different boards the only thing in common really is the > > Xscale core. > > > > Greg Ungerer posted a patch that I echoed. One problem is that is > > appears to be and issue with a calculation. The comment seems to > > indicate that the variable used should be 'namelen' but instead is > > 'count' > > What patch? please forward it here. > > > > > One thing to consider here - the x86 is Little endian. We > are BE on the > > IXP425 > > > > > XFS runs fine on big endian hardware, that is where it was developed. > This is more likely to be a problem in the gcc code generation on > the xscale. It would not be the first time that xfs has pushed gcc > over the edge. There is a lot of 64 bit stuff inside xfs, and we have > seen gcc get very confused about what is in which register. > > Steve > -- Attached file included as plaintext by Ecartis -- Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: Useful Update for XFS on the IXDP425 Date: Thu, 11 Mar 2004 08:55:34 -0800 Message-ID: <802FECEADA78854F8DD69950B138D8C9FFD7E9@orsmsx405.jf.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Useful Update for XFS on the IXDP425 Thread-Index: AcQG+tXi4Qm94O14RUyEOgZMNXLjKQAjGBVA From: "Ranslam, Robert E" To: ALL; The following patch was made by Greg Ungerer in checking out XFS on the IXDP425. This fixed basic issues that could help other that may want to use XFS on BE Xscale (ixp4xx) systems. This was made against xfs v1.3.1, using 2.4.24 based linux from the SnapGear 3.1 distro. Minimal testing was done on an IXDP425. Initial reports indicate that does help.=20=20 - Dave Jiang at intel has reported some success with this patch on 80321 based systems Most of the discussions regarding XFS in the last few days prompted this post, but were made in the arm-linux mailing list. Here is a snippet of the comments that Greg provided when sent the patch to as part of what we were working on. Note: sorry of this appears to be a repost. The initial email seems to have gotten stuck getting to the mailing list > I have a fix for the problem and I can reproduce with XFS on the > IXDP425. With the attached patch applied I can do basic filesystem > manipluations with no problems now (things like copies, deletes, > etc). >=20 > Not to say there isn't more problems but it seems to basically work > reliably with this in place. And this is with all debug and asserts > turned on, so that gives me a little bit more confidence. >=20 > The patch uses a different method to calculate the size of the > secondary directory structure. I think the original calculation > is using the wrong struct size, I would need to consult XFS experts > on the XFS mailing to confirm this fix. --- xfs_dir2_sf.c.org 2004-02-17 14:56:16.000000000 +1000 +++ xfs_dir2_sf.c 2004-02-17 14:55:16.000000000 +1000 @@ -148,6 +148,7 @@ /* * Calculate the new size, see if we should give up yet. */ +#if 0 size =3D XFS_DIR2_SF_HDR_SIZE(i8count) + /* header */ count + /* namelen */ count * (uint)sizeof(xfs_dir2_sf_off_t) + /* offset */ @@ -155,6 +156,13 @@ (i8count ? /* inumber */ (uint)sizeof(xfs_dir2_ino8_t) * count : (uint)sizeof(xfs_dir2_ino4_t) * count); +#endif + size =3D XFS_DIR2_SF_HDR_SIZE(i8count) /* header */ + + namelen + + (count * (sizeof(xfs_dir2_sf_entry_t) - 1)) + - (count * (((i8count =3D=3D 0) ? 1 : 0) * + (sizeof(xfs_dir2_ino8_t) - sizeof(xfs_dir2_ino4_t)))); +=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 if (size > XFS_IFORK_DSIZE(dp)) return size; /* size value is a failure */ } From owner-linux-xfs@oss.sgi.com Thu Mar 11 10:17:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Mar 2004 10:17:59 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2BIHoKO018728 for ; Thu, 11 Mar 2004 10:17:51 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1B1UkW-0001cU-E7; Thu, 11 Mar 2004 18:17:40 +0000 Date: Thu, 11 Mar 2004 18:17:40 +0000 From: Christoph Hellwig To: Vinesh Christopher Cc: "'Eric Sandeen'" , "'linux-xfs@oss.sgi.com'" Subject: Re: Bug : XFS - XSCALE "Directory Not Empty" Message-ID: <20040311181740.A6177@infradead.org> References: <8CCBDD5583C50E4196F012E79439B45C04C9A32D@atl-ms1.megatrends.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <8CCBDD5583C50E4196F012E79439B45C04C9A32D@atl-ms1.megatrends.com>; from vineshc@ami.com on Thu, Mar 11, 2004 at 10:42:44AM -0500 Content-Transfer-Encoding: 8bit X-archive-position: 2426 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 524 Lines: 14 On Thu, Mar 11, 2004 at 10:42:44AM -0500, Vinesh Christopher wrote: > Yes, From a fresh mkfs. > > It works for me on x86 platforms. > > I tried it on two Xscale board, each with > IDE and SCSI disks, and it is the same problem. > In the same setup, I used ext3, it works fine. > This eliminates the hardware issues. have you tried mkfsing a filesystem on arm and mounting it on a pc and vice versa? is your plattform big or little endian and with signed or unsigned char. Are you using v1 directories by any chance? From owner-linux-xfs@oss.sgi.com Thu Mar 11 10:38:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Mar 2004 10:39:08 -0800 (PST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2BIcvKO020368 for ; Thu, 11 Mar 2004 10:38:58 -0800 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2BIgXNU003861; Thu, 11 Mar 2004 18:42:33 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2BIUmQH010463; Thu, 11 Mar 2004 18:32:49 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031110384415015 ; Thu, 11 Mar 2004 10:38:44 -0800 Received: from orsmsx405.amr.corp.intel.com ([192.168.65.46]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Mar 2004 10:38:44 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: XSF on Xscale Date: Thu, 11 Mar 2004 10:38:44 -0800 Message-ID: <802FECEADA78854F8DD69950B138D8C9025ABC19@orsmsx405.jf.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XSF on Xscale Thread-Index: AcQHkdq3W32UAZPiQ5u+6drSuBLlowAACzWg From: "Ranslam, Robert E" To: "Eric Sandeen" Cc: "Steve Lord" , , "Nathan Scott" , "Vinesh Christopher" X-OriginalArrivalTime: 11 Mar 2004 18:38:44.0663 (UTC) FILETIME=[15473C70:01C40798] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i2BIcwKO020372 X-archive-position: 2427 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robert.e.ranslam@intel.com Precedence: bulk X-list: linux-xfs Content-Length: 4106 Lines: 129 Changing the Subject to something more relevant Just sent the patch directly to you. Also saw Vinesh post it We do have customers that are interested in XFS it seems like all of a sudden it's the "hot thing". Greg Ungerer ( gerg@snapgear.com) did some initial testing to help out an ODM that was hacking (weakly) at it. MontaVista 'claims' to support it. But they could see the same problem Greg saw on the IXDP425 - I do not think that it is a "GCC problem" as the patch adds a variable that was missing in the original code. But then Greg deferred "Judgment" to the XFS experts on the calculation. There could be other issues that ARE tool chain related. I can't really rule anything out yet as I have personally not done the testing. From Vinesh's reply, it looks as if it is not a BE/LE thing - I'm always concerned about this though as I have had to track down enough issues related to drivers/firmware assumed LE always. Also comments from Steve Lord make me feel better about the LE/BE stuff I have seem in other systems. RR > -----Original Message----- > From: Eric Sandeen [mailto:sandeen@sgi.com] > Sent: Thursday, March 11, 2004 9:54 AM > To: Ranslam, Robert E > Subject: RE: Bug : XFS - XSCALE "Directory Not Empty" > > > Hi Robert - > > Where was the patch posted? I have not seen it yet. > > Sorry I was being dense about xscale, I was not familiar with the > technology. If Intel is keen to have xfs run properly on the board, > perhaps we should look into getting some hardware to test on. > While SGI > probably doesn't have a clear business interest in XFS on > XSCALE, I have > a personal linux-hacker interest in making sure that xfs runs properly > on all platforms that Linux supports... :) > > Thanks, > > -Eric > > On Thu, 2004-03-11 at 11:39, Ranslam, Robert E wrote: > > FYI: > > Its also in the IXDP425 as well as the IQ80321. These are two > > completely different boards the only thing in common really is the > > Xscale core. > > > > Greg Ungerer posted a patch that I echoed. One problem is that is > > appears to be and issue with a calculation. The comment seems to > > indicate that the variable used should be 'namelen' but instead is > > 'count' > > > > One thing to consider here - the x86 is Little endian. We > are BE on the > > IXP425 > > > > RR > > > > > -----Original Message----- > > > From: linux-xfs-bounce@oss.sgi.com > > > [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Vinesh > Christopher > > > Sent: Thursday, March 11, 2004 7:40 AM > > > To: 'Nathan Scott'; Vinesh Christopher > > > Cc: 'linux-xfs@oss.sgi.com' > > > Subject: RE: Bug : XFS - XSCALE "Directory Not Empty" > > > > > > > > > It works on x86 platforms for me. The problem is > > > With the XSCALE board. > > > > > > -----Original Message----- > > > From: Nathan Scott [mailto:nathans@sgi.com] > > > Sent: Wednesday, March 10, 2004 8:11 PM > > > To: Vinesh Christopher > > > Cc: 'linux-xfs@oss.sgi.com' > > > Subject: Re: Bug : XFS - XSCALE "Directory Not Empty" > > > > > > On Wed, Mar 10, 2004 at 02:14:58PM -0500, Vinesh > Christopher wrote: > > > > > > > > Intel IQ80321 (Xscale) Evaluation Board > > > > Running Linux 2.6.0 with -rmk2 patches > > > > xfsprogs_2.6.3-1 is taken from debian > > > > > > > > I did the following > > > > > > > > # mkfs.xfs /dev/sda1 > > > > # mount /dev/sda1 /mnt > > > > # cd /mnt > > > > # mkdir t > > > > # cp /lib/* t > > > > # rm -r -f t > > > > rm: cannot remove directory 't' : Directory not empty > > > > # > > > > > > Any errors on your console or in your system logs? > > > > > > I tried this locally and (not really surprisingly) it works > > > just fine on my system. > > > > > > > I tried with 2.4.21 and XFS 1.3.1 patches -> same problem > > > > > > Uhrm, odd - there are lots of people using XFS from that kernel. > > > I'm inclined to suspect your hardware at this stage. > > > > > > cheers. > > > > > > -- > > > Nathan > > > > > > > > > > -- > Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. 651-683-3102 > > From owner-linux-xfs@oss.sgi.com Thu Mar 11 10:49:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Mar 2004 10:50:02 -0800 (PST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2BInqKO021193 for ; Thu, 11 Mar 2004 10:49:53 -0800 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2BIrZNU012030; Thu, 11 Mar 2004 18:53:35 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2BIhePL018380; Thu, 11 Mar 2004 18:43:48 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031110494316859 ; Thu, 11 Mar 2004 10:49:44 -0800 Received: from orsmsx405.amr.corp.intel.com ([192.168.65.46]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Mar 2004 10:49:43 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: Bug : XFS - XSCALE "Directory Not Empty" Date: Thu, 11 Mar 2004 10:49:43 -0800 Message-ID: <802FECEADA78854F8DD69950B138D8C9025ABC54@orsmsx405.jf.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bug : XFS - XSCALE "Directory Not Empty" Thread-Index: AcQHlLMpUaz2PZjWQpCIwAX69Wk0VQAA4PYA From: "Ranslam, Robert E" To: "Steve Lord" Cc: "Vinesh Christopher" , "Nathan Scott" , , X-OriginalArrivalTime: 11 Mar 2004 18:49:43.0933 (UTC) FILETIME=[9E3BDAD0:01C40799] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i2BInrKO021196 X-archive-position: 2428 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robert.e.ranslam@intel.com Precedence: bulk X-list: linux-xfs Content-Length: 1513 Lines: 49 > -----Original Message----- > From: Steve Lord [mailto:lord@xfs.org] > Sent: Thursday, March 11, 2004 10:09 AM > > Ranslam, Robert E wrote: > > FYI: > > Its also in the IXDP425 as well as the IQ80321. These are two > > completely different boards the only thing in common really is the > > Xscale core. > > > > Greg Ungerer posted a patch that I echoed. One problem is that is > > appears to be and issue with a calculation. The comment seems to > > indicate that the variable used should be 'namelen' but instead is > > 'count' > > What patch? please forward it here. > Vinesh posted. > > > > One thing to consider here - the x86 is Little endian. We > are BE on the > > IXP425 > > > > > XFS runs fine on big endian hardware, that is where it was developed. > This is more likely to be a problem in the gcc code generation on > the xscale. It would not be the first time that xfs has pushed gcc > over the edge. There is a lot of 64 bit stuff inside xfs, and we have > seen gcc get very confused about what is in which register. > > Steve > Thanks! That alleviated one of my concerns... Ok, so we may need to 'fixup' the code is small places to temporarily work around compiler/toolchain issues. No sure what/where those would be yet - maybe the patch is the only place where this is required. I guess first thing is - Does the patch actually address a code issue? Or is the tool chain generating the wrong code? What should the calculation the patch 'fixes-up' really result in? RR From owner-linux-xfs@oss.sgi.com Thu Mar 11 11:02:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Mar 2004 11:03:09 -0800 (PST) Received: from localhost.localdomain (outgoingmail.adic.com [63.81.117.28]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2BJ2uKO021788 for ; Thu, 11 Mar 2004 11:02:57 -0800 Received: from xfs.org (jen [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i2BIvATo004714; Thu, 11 Mar 2004 12:57:11 -0600 Message-ID: <4050B686.1040908@xfs.org> Date: Thu, 11 Mar 2004 12:57:10 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ranslam, Robert E" CC: Eric Sandeen , linux-xfs@oss.sgi.com, Nathan Scott , Vinesh Christopher Subject: Re: XSF on Xscale References: <802FECEADA78854F8DD69950B138D8C9025ABC19@orsmsx405.jf.intel.com> In-Reply-To: <802FECEADA78854F8DD69950B138D8C9025ABC19@orsmsx405.jf.intel.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2429 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 2002 Lines: 58 Ranslam, Robert E wrote: > Changing the Subject to something more relevant > > Just sent the patch directly to you. Also saw Vinesh post it > The old code looks correct to me, the comments are confusing: size = XFS_DIR2_SF_HDR_SIZE(i8count) + /* header */ count + /* namelen */ count * (uint)sizeof(xfs_dir2_sf_off_t) + /* offset */ namelen + /* name */ (i8count ? /* inumber */ (uint)sizeof(xfs_dir2_ino8_t) * count : (uint)sizeof(xfs_dir2_ino4_t) * count); i8count is set based on their being a 64 bit inode in the directory, a short form dir will attempt to pack inode numbers into 4 bytes if they will all fit. So we have: // the size of the header record XFS_DIR2_SF_HDR_SIZE(i8count) + // 1 byte for the namelen of each entry count + // one off_t thing for each entry count * (uint)sizeof(xfs_dir2_sf_off_t) + // space for the names namelen + // space for count 4 or 8 byte inode numbers (i8count ? /* inumber */ (uint)sizeof(xfs_dir2_ino8_t) * count : (uint)sizeof(xfs_dir2_ino4_t) * count); So the use of count where it says namelen is correct, we have 1 byte for each string length. You could probably restructure this into something a little less complex: XFS_DIR2_SF_HDR_SIZE(i8count) + namelen + count * (sizeof(xfs_dir2_sf_off_t) + 1 + (i8count ? sizeof(xfs_dir2_ino8_t) : sizeof(xfs_dir2_ino4_t))) I would actually break the conditional expression out of there and see if that makes a difference. inode_size = i8count ? sizeof(xfs_dir2_ino8_t) : sizeof(xfs_dir2_ino4_t); size = XFS_DIR2_SF_HDR_SIZE(i8count) + count * (sizeof(xfs_dir2_sf_off_t) + 1 + inode_size); Steve From owner-linux-xfs@oss.sgi.com Thu Mar 11 11:45:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Mar 2004 11:45:25 -0800 (PST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2BJjGKO023213 for ; Thu, 11 Mar 2004 11:45:19 -0800 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2ANv1OC016311; Wed, 10 Mar 2004 23:57:01 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2ANsnAX010025; Wed, 10 Mar 2004 23:55:01 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031015530902662 ; Wed, 10 Mar 2004 15:53:09 -0800 Received: from orsmsx405.amr.corp.intel.com ([192.168.65.46]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Mar 2004 15:53:09 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-type: text/plain X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: Update for XFS on the IXDP425 Date: Wed, 10 Mar 2004 15:53:08 -0800 Message-ID: <802FECEADA78854F8DD69950B138D8C9025AB61F@orsmsx405.jf.intel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Update for XFS on the IXDP425 Thread-Index: AcQG+tXi4Qm94O14RUyEOgZMNXLjKQ== From: "Ranslam, Robert E" To: Cc: X-OriginalArrivalTime: 10 Mar 2004 23:53:09.0302 (UTC) FILETIME=[D710F560:01C406FA] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-archive-position: 2430 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robert.e.ranslam@intel.com Precedence: bulk X-list: linux-xfs Content-Length: 1069 Lines: 30 ALL; Attached is a patch that Greg Ungerer made in checking out XFS on the IXDP425. This fixed basic issues that could help other that would want to use XFS on BE Xscale Linux systems. Initial reports indicate that does help. This was made against xfs v1.3.1 > I have a fix for the problem and I can reproduce with XFS on the > IXDP425. With the attached patch applied I can do basic filesystem > manipluations with no problems now (things like copies, deletes, > etc). > > Not to say there isn't more problems but it seems to basically work > reliably with this in place. And this is with all debug and asserts > turned on, so that gives me a little bit more confidence. > > The patch uses a different method to calculate the size of the > secondary directory structure. I think the original calculation > is using the wrong struct size, I would need to consult XFS experts > on the XFS mailing to confirm this fix. -- Binary/unsupported file stripped by Ecartis -- -- Type: application/octet-stream -- File: xfs-20040217.patch -- Desc: xfs-20040217.patch From owner-linux-xfs@oss.sgi.com Thu Mar 11 11:58:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Mar 2004 11:58:51 -0800 (PST) Received: from orc.rlhc.net (h24-77-172.250.sbm.shawcable.net [24.77.172.250]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2BJwkKO024172 for ; Thu, 11 Mar 2004 11:58:46 -0800 Received: from localhost (localhost [127.0.0.1]) by orc.rlhc.net (Postfix) with ESMTP id 4111CD438 for ; Thu, 11 Mar 2004 14:00:37 -0600 (CST) Received: from orc.rlhc.net ([127.0.0.1]) by localhost (orc.rlhc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30918-05 for ; Thu, 11 Mar 2004 14:00:35 -0600 (CST) Received: from mail.rlhc.net (localhost [127.0.0.1]) by orc.rlhc.net (Postfix) with SMTP id D79BD16181 for ; Thu, 11 Mar 2004 14:00:35 -0600 (CST) Received: from 24.77.172.251 (SquirrelMail authenticated user rich) by mail.rlhc.net with HTTP; Thu, 11 Mar 2004 14:00:35 -0600 (CST) Message-ID: <48987.24.77.172.251.1079035235.squirrel@mail.rlhc.net> Date: Thu, 11 Mar 2004 14:00:35 -0600 (CST) Subject: acl patch for 2.4.25 From: "Richard Houston" To: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/2.0 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at rlhc.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i2BJwkKO024173 X-archive-position: 2431 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rhouston@rlhc.net Precedence: bulk X-list: linux-xfs Content-Length: 474 Lines: 20 Hi all, Was wondering if anyone has a patch to add XFS acl support for the 2.4.25 kernel? I have Posix ACL and EA patches installed but need the XFS acl support still. Thanks in advance! Regards, +------------------------------------------+ | Richard Houston .^. | | R.L.H. Consulting /V\ | | E-Mail /( )\ | | WWW ^^-^^ | +------------------------------------------+ From owner-linux-xfs@oss.sgi.com Thu Mar 11 12:56:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Mar 2004 12:56:05 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2BKu2KO005363 for ; Thu, 11 Mar 2004 12:56:02 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2BKn902024462 for ; Thu, 11 Mar 2004 12:49:09 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2BKn8Ke35307978; Thu, 11 Mar 2004 14:49:09 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i2BKn8Eq1882561; Thu, 11 Mar 2004 14:49:08 -0600 (CST) Subject: Re: acl patch for 2.4.25 From: Eric Sandeen To: Richard Houston Cc: linux-xfs@oss.sgi.com In-Reply-To: <48987.24.77.172.251.1079035235.squirrel@mail.rlhc.net> References: <48987.24.77.172.251.1079035235.squirrel@mail.rlhc.net> Content-type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1079038147.23366.20.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 11 Mar 2004 14:49:08 -0600 Content-Transfer-Encoding: 8bit X-archive-position: 2432 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 866 Lines: 29 Searching the mailing list archives will help you here. http://oss.sgi.com/cgi-bin/namazu.cgi?query=2.4.25+acl&submit=Search%21&idxname=linux-xfs&max=20&result=normal&sort=score On Thu, 2004-03-11 at 14:00, Richard Houston wrote: > Hi all, > > Was wondering if anyone has a patch to add XFS acl support for the 2.4.25 > kernel? I have Posix ACL and EA patches installed but need the XFS acl > support still. > > Thanks in advance! > > > > Regards, > +------------------------------------------+ > | Richard Houston .^. | > | R.L.H. Consulting /V\ | > | E-Mail /( )\ | > | WWW ^^-^^ | > +------------------------------------------+ > -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Mar 11 14:25:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Mar 2004 14:25:45 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2BMPgKO007471 for ; Thu, 11 Mar 2004 14:25:42 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2BMKoil026237 for ; Thu, 11 Mar 2004 16:21:12 -0600 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA06529; Fri, 12 Mar 2004 09:20:48 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2BMKkFx231240; Fri, 12 Mar 2004 09:20:47 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i2BMKFTG000873; Fri, 12 Mar 2004 09:20:16 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i2BMK6Qa000871; Fri, 12 Mar 2004 09:20:06 +1100 Date: Fri, 12 Mar 2004 09:20:06 +1100 From: Nathan Scott To: Richard Houston Cc: linux-xfs@oss.sgi.com Subject: Re: acl patch for 2.4.25 Message-ID: <20040311222006.GB736@frodo> References: <48987.24.77.172.251.1079035235.squirrel@mail.rlhc.net> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48987.24.77.172.251.1079035235.squirrel@mail.rlhc.net> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2433 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1808 Lines: 51 On Thu, Mar 11, 2004 at 02:00:35PM -0600, Richard Houston wrote: > Hi all, > > Was wondering if anyone has a patch to add XFS acl support for the 2.4.25 > kernel? I have Posix ACL and EA patches installed but need the XFS acl > support still. > > Thanks in advance! > If you have Andreas' patches installed already, this should be the only patch you need to get up and running. I've asked if Andreas will keep this on his site for us with the other ACL & EA patches so that this issue doesn't keep coming up. cheers. -- Nathan --- fs/Config.in.orig 2004-03-12 08:33:24.695789608 +1100 +++ fs/Config.in 2004-03-12 08:56:50.314103144 +1100 @@ -103,6 +103,7 @@ tristate 'XFS filesystem support' CONFIG_XFS_FS dep_mbool ' Quota support' CONFIG_XFS_QUOTA $CONFIG_XFS_FS +dep_mbool ' POSIX ACL support' CONFIG_XFS_POSIX_ACL $CONFIG_XFS_FS dep_mbool ' Realtime support (EXPERIMENTAL)' CONFIG_XFS_RT $CONFIG_XFS_FS $CONFIG_EXPERIMENTAL dep_mbool ' Tracing support (EXPERIMENTAL)' CONFIG_XFS_TRACE $CONFIG_XFS_FS $CONFIG_EXPERIMENTAL dep_mbool ' Debugging support (EXPERIMENTAL)' CONFIG_XFS_DEBUG $CONFIG_XFS_FS $CONFIG_EXPERIMENTAL --- Documentation/Configure.help.orig 2004-03-12 08:33:38.387708120 +1100 +++ Documentation/Configure.help 2004-03-12 08:57:19.999590264 +1100 @@ -17370,6 +17370,16 @@ If unsure, say N. +POSIX ACL support +CONFIG_XFS_POSIX_ACL + POSIX Access Control Lists (ACLs) support permissions for users and + groups beyond the owner/group/world scheme. + + To learn more about Access Control Lists, visit the POSIX ACLs for + Linux website . + + If you don't know what Access Control Lists are, say N. + Tracing support (EXPERIMENTAL) CONFIG_XFS_TRACE Say Y here to get an XFS build with activity tracing enabled. From owner-linux-xfs@oss.sgi.com Thu Mar 11 16:32:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Mar 2004 16:32:23 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2C0WJKO015167 for ; Thu, 11 Mar 2004 16:32:19 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2C0WJqi015166 for linux-xfs@oss.sgi.com; Thu, 11 Mar 2004 16:32:19 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2C0WHKO015154 for ; Thu, 11 Mar 2004 16:32:17 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2C09HYr011582; Thu, 11 Mar 2004 16:09:17 -0800 Date: Thu, 11 Mar 2004 16:09:17 -0800 Message-Id: <200403120009.i2C09HYr011582@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 313] xfs_log_write: reservation ran out. Need to up reservation X-Bugzilla-Reason: AssignedTo X-archive-position: 2434 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 452 Lines: 16 http://oss.sgi.com/bugzilla/show_bug.cgi?id=313 ------- Additional Comments From akp@cohaesio.com 2004-11-03 16:09 PDT ------- Just a quick note to let you know, that I just reproduced this with Linux 2.6.4 final. As this system isn't in production yet, I don't mind trying out experimental patches that may fix the problem. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 11 22:32:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Mar 2004 22:33:07 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2C6WlKO028764 for ; Thu, 11 Mar 2004 22:32:47 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2C8Xm2c020573 for ; Fri, 12 Mar 2004 00:33:48 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA13276 for ; Fri, 12 Mar 2004 17:32:37 +1100 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i2C6WbmX031662 for ; Fri, 12 Mar 2004 17:32:37 +1100 Received: (from nathans@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i2C6WaGb031660 for linux-xfs@oss.sgi.com; Fri, 12 Mar 2004 17:32:36 +1100 Date: Fri, 12 Mar 2004 17:32:36 +1100 From: Nathan Scott Message-Id: <200403120632.i2C6WaGb031660@sherman.melbourne.sgi.com> Subject: TAKE 904196 - Merge up to 2.6.4 Apparently-To: X-archive-position: 2435 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 106039 Lines: 3154 Date: Thu Mar 11 22:17:49 PST 2004 Workarea: sherman.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:168325a drivers/net/ibmveth.c - 1.1 drivers/net/ibmveth.h - 1.1 drivers/net/e100.c - 1.1 drivers/net/irda/stir4200.c - 1.1 drivers/pci/hotplug/pciehp.h - 1.1 security/selinux/netlink.c - 1.1 drivers/pci/hotplug/pciehp_core.c - 1.1 drivers/pci/hotplug/pciehp_ctrl.c - 1.1 drivers/pci/hotplug/pciehp_hpc.c - 1.1 Documentation/debugging-modules.txt - 1.1 drivers/pci/hotplug/pciehp_pci.c - 1.1 Documentation/dvb/avermedia.txt - 1.1 scripts/sumversion.c - 1.1 scripts/gcc-version.sh - 1.1 net/sunrpc/auth_gss/svcauth_gss.c - 1.1 drivers/pci/hotplug/pciehp_sysfs.c - 1.1 Documentation/filesystems/hfs.txt - 1.1 drivers/pci/hotplug/pciehprm.h - 1.1 drivers/pci/hotplug/pciehprm_acpi.c - 1.1 drivers/pci/hotplug/pciehprm_nonacpi.c - 1.1 drivers/pci/hotplug/pciehprm_nonacpi.h - 1.1 drivers/pci/hotplug/rpadlpar.h - 1.1 drivers/pci/hotplug/rpadlpar_core.c - 1.1 drivers/pci/hotplug/rpadlpar_sysfs.c - 1.1 drivers/pci/hotplug/rpaphp.h - 1.1 drivers/pci/hotplug/rpaphp_core.c - 1.1 drivers/pci/hotplug/rpaphp_pci.c - 1.1 drivers/pci/hotplug/shpchp.h - 1.1 drivers/pci/hotplug/shpchp_core.c - 1.1 drivers/pci/hotplug/shpchp_ctrl.c - 1.1 drivers/pci/hotplug/shpchp_hpc.c - 1.1 drivers/pci/hotplug/shpchp_pci.c - 1.1 Documentation/networking/netif-msg.txt - 1.1 drivers/pci/hotplug/shpchp_sysfs.c - 1.1 drivers/pci/hotplug/shpchprm.h - 1.1 drivers/pci/hotplug/shpchprm_acpi.c - 1.1 drivers/pci/hotplug/shpchprm_legacy.c - 1.1 drivers/pci/hotplug/shpchprm_legacy.h - 1.1 drivers/pci/hotplug/shpchprm_nonacpi.c - 1.1 drivers/pci/hotplug/shpchprm_nonacpi.h - 1.1 drivers/s390/block/dasd_cmb.c - 1.1 drivers/s390/block/dcssblk.c - 1.1 drivers/misc/ibmasm/uart.c - 1.1 drivers/misc/ibmasm/remote.h - 1.1 drivers/misc/ibmasm/remote.c - 1.1 drivers/misc/ibmasm/r_heartbeat.c - 1.1 drivers/misc/ibmasm/module.c - 1.1 drivers/misc/ibmasm/lowlevel.h - 1.1 drivers/misc/ibmasm/lowlevel.c - 1.1 drivers/misc/ibmasm/ibmasmfs.c - 1.1 drivers/misc/ibmasm/ibmasm.h - 1.1 drivers/misc/ibmasm/i2o.h - 1.1 drivers/misc/ibmasm/heartbeat.c - 1.1 drivers/misc/ibmasm/event.c - 1.1 drivers/misc/ibmasm/dot_command.h - 1.1 drivers/misc/ibmasm/dot_command.c - 1.1 drivers/misc/ibmasm/command.c - 1.1 Documentation/sound/oss/rme96xx - 1.1 drivers/misc/ibmasm/Makefile - 1.1 drivers/s390/char/tape_class.c - 1.1 drivers/s390/char/tape_class.h - 1.1 drivers/s390/cio/cmf.c - 1.1 Documentation/video4linux/bttv/Modprobe.conf - 1.1 drivers/s390/net/smsgiucv.c - 1.1 drivers/s390/net/smsgiucv.h - 1.1 drivers/scsi/aacraid/rkt.c - 1.1 drivers/serial/au1x00_uart.c - 1.1 drivers/serial/dz.c - 1.1 drivers/serial/dz.h - 1.1 drivers/serial/ip22zilog.c - 1.1 drivers/serial/ip22zilog.h - 1.1 drivers/serial/pxa.c - 1.1 fs/hfs/btree.h - 1.1 fs/hfs/hfs_fs.h - 1.1 fs/hfsplus/Makefile - 1.1 fs/hfsplus/bfind.c - 1.1 fs/hfsplus/bitmap.c - 1.1 fs/hfsplus/bnode.c - 1.1 fs/hfsplus/brec.c - 1.1 fs/hfsplus/btree.c - 1.1 fs/hfsplus/catalog.c - 1.1 drivers/media/video/saa5246a.h - 1.1 drivers/media/video/saa5246a.c - 1.1 fs/hfsplus/dir.c - 1.1 fs/hfsplus/extents.c - 1.1 fs/hfsplus/hfsplus_fs.h - 1.1 fs/hfsplus/hfsplus_raw.h - 1.1 fs/hfsplus/inode.c - 1.1 drivers/media/radio/radio-sf16fmr2.c - 1.1 fs/hfsplus/ioctl.c - 1.1 fs/hfsplus/options.c - 1.1 fs/hfsplus/part_tbl.c - 1.1 fs/hfsplus/super.c - 1.1 fs/hfsplus/tables.c - 1.1 fs/hfsplus/unicode.c - 1.1 fs/hfsplus/wrapper.c - 1.1 fs/nfsd/nfs4idmap.c - 1.1 include/asm-generic/dma-mapping-broken.h - 1.1 include/asm-ia64/cyclone.h - 1.1 include/asm-mips/cpu-features.h - 1.1 include/asm-mips/hazards.h - 1.1 include/asm-mips/mach-atlas/mc146818rtc.h - 1.1 include/asm-mips/mach-au1x00/au1000.h - 1.1 include/asm-mips/mach-au1x00/au1000_dma.h - 1.1 include/asm-mips/mach-au1x00/au1000_gpio.h - 1.1 include/asm-mips/mach-au1x00/au1000_pcmcia.h - 1.1 arch/arm/mm/abort-ev6.S - 1.1 include/asm-mips/mach-au1x00/au1000_usbdev.h - 1.1 arch/arm/mm/blockops.c - 1.1 arch/arm/mm/cache-v6.S - 1.1 arch/arm/mm/copypage-v6.c - 1.1 include/asm-mips/mach-au1x00/timex.h - 1.1 arch/arm/mm/proc-arm925.S - 1.1 include/asm-mips/mach-db1x00/db1x00.h - 1.1 arch/arm/mm/proc-v6.S - 1.1 arch/arm/mm/tlb-v6.S - 1.1 include/asm-mips/mach-ddb5074/mc146818rtc.h - 1.1 arch/arm/oprofile/Kconfig - 1.1 arch/arm/oprofile/Makefile - 1.1 arch/arm/oprofile/init.c - 1.1 include/asm-mips/mach-dec/mc146818rtc.h - 1.1 include/asm-mips/mach-dec/param.h - 1.1 include/asm-mips/mach-ev64120/mach-gt64120.h - 1.1 include/asm-mips/mach-ev96100/mach-gt64120.h - 1.1 include/asm-mips/mach-generic/cpu-feature-overrides.h - 1.1 include/asm-mips/mach-generic/floppy.h - 1.1 include/asm-mips/mach-generic/ide.h - 1.1 include/asm-mips/mach-generic/irq.h - 1.1 include/asm-mips/mach-generic/mangle-port.h - 1.1 include/asm-mips/mach-generic/mc146818rtc.h - 1.1 arch/h8300/Kconfig.ide - 1.1 include/asm-mips/mach-generic/param.h - 1.1 include/asm-mips/mach-generic/spaces.h - 1.1 include/asm-mips/mach-generic/timex.h - 1.1 include/asm-mips/mach-ip22/cpu-feature-overrides.h - 1.1 include/asm-mips/mach-ip22/ds1286.h - 1.1 include/asm-mips/mach-ip27/cpu-feature-overrides.h - 1.1 include/asm-mips/mach-ip27/irq.h - 1.1 drivers/md/dm-crypt.c - 1.1 drivers/md/dm-bio-list.h - 1.1 include/asm-mips/mach-ip27/mangle-port.h - 1.1 include/asm-mips/mach-ip27/mmzone.h - 1.1 include/asm-mips/mach-ip27/spaces.h - 1.1 include/asm-mips/mach-ip32/mangle-port.h - 1.1 include/asm-mips/mach-ip32/mc146818rtc.h - 1.1 include/asm-mips/mach-jazz/floppy.h - 1.1 include/asm-mips/mach-jazz/mc146818rtc.h - 1.1 include/asm-mips/mach-jazz/param.h - 1.1 include/asm-mips/mach-jazz/timex.h - 1.1 include/asm-mips/mach-jmr3927/asm/ds1742.h - 1.1 include/asm-mips/mach-lasat/mach-gt64120.h - 1.1 include/asm-mips/mach-mips/mach-gt64120.h - 1.1 include/asm-mips/mach-mips/mc146818rtc.h - 1.1 include/asm-mips/mach-ocelot/mach-gt64120.h - 1.1 include/asm-mips/mach-pb1x00/mc146818rtc.h - 1.1 include/asm-mips/mach-pb1x00/pb1000.h - 1.1 include/asm-mips/mach-pb1x00/pb1100.h - 1.1 include/asm-mips/mach-pb1x00/pb1500.h - 1.1 include/asm-mips/mach-rm200/cpu-feature-overrides.h - 1.1 include/asm-mips/mach-rm200/mc146818rtc.h - 1.1 include/asm-mips/mach-vr41xx/timex.h - 1.1 include/asm-mips/mc146818-time.h - 1.1 include/asm-mips/numnodes.h - 1.1 drivers/isdn/hisax/teles_cs.c - 1.1 drivers/isdn/hisax/isdnhdlc.h - 1.1 drivers/isdn/hisax/isdnhdlc.c - 1.1 drivers/isdn/hisax/hisax_cfg.h - 1.1 drivers/isdn/hisax/hfc_usb.c - 1.1 drivers/ieee1394/csr1212.h - 1.1 drivers/ieee1394/csr1212.c - 1.1 drivers/ieee1394/config_roms.h - 1.1 drivers/ieee1394/config_roms.c - 1.1 include/asm-mips/prefetch.h - 1.1 include/asm-mips/sgi/pi1.h - 1.1 drivers/char/watchdog/pcwd_usb.c - 1.1 include/asm-mips/sn/hub.h - 1.1 drivers/char/agp/efficeon-agp.c - 1.1 arch/i386/kernel/early_printk.c - 1.1 drivers/cdrom/viocd.c - 1.1 include/asm-mips/titan_dep.h - 1.1 drivers/block/viodasd.c - 1.1 include/asm-mips/vr41xx/vrc4171.h - 1.1 include/asm-mips/xxs1500.h - 1.1 crypto/scatterwalk.h - 1.1 crypto/scatterwalk.c - 1.1 crypto/arc4.c - 1.1 arch/x86_64/kernel/mce.c - 1.1 arch/sparc/lib/atomic32.c - 1.1 include/asm-ppc64/iommu.h - 1.1 include/asm-s390/cmb.h - 1.1 arch/s390/mm/extmem.c - 1.1 arch/s390/mm/cmm.c - 1.1 arch/s390/lib/strcpy64.S - 1.1 arch/s390/lib/strcpy.S - 1.1 arch/s390/appldata/appldata_os.c - 1.1 arch/s390/appldata/appldata_net_sum.c - 1.1 arch/s390/appldata/appldata_mem.c - 1.1 arch/s390/appldata/appldata_base.c - 1.1 arch/s390/appldata/appldata.h - 1.1 arch/i386/kernel/timers/timer_pm.c - 1.1 arch/s390/appldata/Makefile - 1.1 arch/ppc64/mm/tlb.c - 1.1 include/asm-s390/extmem.h - 1.1 include/asm-s390/timer.h - 1.1 include/asm-x86_64/mce.h - 1.1 include/linux/kthread.h - 1.1 include/linux/nfsd_idmap.h - 1.1 include/linux/selinux_netlink.h - 1.1 include/linux/stop_machine.h - 1.1 include/linux/sunrpc/svcauth_gss.h - 1.1 arch/ppc64/kernel/pmac_iommu.c - 1.1 include/linux/syscalls.h - 1.1 arch/ppc64/kernel/pci_iommu.c - 1.1 arch/i386/pci/mmconfig.c - 1.1 include/video/cvisionppc.h - 1.1 arch/ppc64/kernel/pSeries_iommu.c - 1.1 include/video/permedia2.h - 1.1 arch/ppc64/kernel/iommu.c - 1.1 arch/ppc64/kernel/iSeries_iommu.c - 1.1 kernel/kthread.c - 1.1 arch/ppc64/configs/iSeries_defconfig - 1.1 kernel/stop_machine.c - 1.1 net/bluetooth/hci_sysfs.c - 1.1 arch/ia64/install.sh - 1.1 arch/mips/vr41xx/common/vrc4171.c - 1.1 arch/mips/vr41xx/common/rtc.c - 1.1 arch/ia64/kernel/cyclone.c - 1.1 arch/mips/vr41xx/common/pmu.c - 1.1 arch/mips/vr41xx/common/ksyms.c - 1.1 arch/mips/sgi-ip27/ip27-smp.c - 1.1 arch/mips/pmc-sierra/yosemite/smp.c - 1.1 arch/mips/pmc-sierra/yosemite/setup.h - 1.1 arch/mips/pmc-sierra/yosemite/setup.c - 1.1 arch/mips/pmc-sierra/yosemite/prom.c - 1.1 arch/mips/pmc-sierra/yosemite/irq.c - 1.1 arch/mips/pmc-sierra/yosemite/irq-handler.S - 1.1 arch/mips/pmc-sierra/yosemite/i2c-yosemite.h - 1.1 arch/mips/pmc-sierra/yosemite/i2c-yosemite.c - 1.1 arch/mips/pmc-sierra/yosemite/ht.c - 1.1 arch/mips/pmc-sierra/yosemite/ht-irq.c - 1.1 arch/mips/pmc-sierra/yosemite/atmel_read_eeprom.h - 1.1 arch/mips/pmc-sierra/yosemite/atmel_read_eeprom.c - 1.1 arch/mips/pmc-sierra/yosemite/Makefile - 1.1 arch/mips/pci/pci-ocelot.c - 1.1 arch/mips/pci/pci-jmr3927.c - 1.1 arch/mips/pci/pci-ev96100.c - 1.1 arch/mips/pci/ops-tx4927.c - 1.1 arch/mips/pci/ops-tx3927.c - 1.1 arch/mips/pci/ops-titan.c - 1.1 arch/mips/pci/ops-sni.c - 1.1 arch/mips/pci/ops-nile4.c - 1.1 arch/mips/pci/ops-mv64340.c - 1.1 arch/mips/pci/ops-msc.c - 1.1 arch/mips/pci/ops-mace.c - 1.1 arch/mips/pci/ops-gt96100.c - 1.1 arch/mips/pci/ops-gt64120.c - 1.1 arch/mips/pci/ops-gt64111.c - 1.1 net/irda/irmod.c - 1.1 arch/mips/pci/ops-bonito64.c - 1.1 arch/mips/pci/fixup-yosemite.c - 1.1 arch/mips/pci/fixup-sni.c - 1.1 arch/mips/pci/fixup-rbtx4927.c - 1.1 arch/mips/pci/fixup-malta.c - 1.1 arch/mips/pci/fixup-ip32.c - 1.1 arch/mips/pci/fixup-ev96100.c - 1.1 arch/mips/pci/fixup-ev64120.c - 1.1 arch/mips/pci/fixup-ddb5477.c - 1.1 arch/mips/pci/fixup-ddb5074.c - 1.1 arch/mips/pci/fixup-cobalt.c - 1.1 arch/mips/pci/fixup-atlas.c - 1.1 arch/mips/momentum/jaguar_atx/setup.c - 1.1 arch/mips/momentum/jaguar_atx/reset.c - 1.1 arch/mips/momentum/jaguar_atx/prom.c - 1.1 arch/m68k/kernel/asm-offsets.c - 1.1 arch/mips/momentum/jaguar_atx/pci.c - 1.1 arch/mips/momentum/jaguar_atx/pci-irq.c - 1.1 arch/mips/momentum/jaguar_atx/mv-irq.c - 1.1 arch/mips/momentum/jaguar_atx/jaguar_atx_fpga.h - 1.1 arch/mips/momentum/jaguar_atx/irq.c - 1.1 arch/mips/momentum/jaguar_atx/int-handler.S - 1.1 arch/mips/momentum/jaguar_atx/dbg_io.c - 1.1 arch/mips/momentum/jaguar_atx/Makefile - 1.1 arch/mips/mm/pg-r4k.c - 1.1 arch/mips/mm/init.c - 1.1 arch/mips/mm/dma-noncoherent.c - 1.1 arch/mips/mm/dma-ip27.c - 1.1 arch/mips/mm/dma-coherent.c - 1.1 arch/mips/mips-boards/generic/pci.c - 1.1 arch/mips/mips-boards/atlas/atlas_gdb.c - 1.1 arch/mips/lib/strnlen_user.S - 1.1 arch/mips/lib/strncpy_user.S - 1.1 arch/mips/lib/strlen_user.S - 1.1 arch/mips/lib/dec_and_lock.c - 1.1 arch/mips/lasat/pci.c - 1.1 arch/mips/kernel/irq-rm7000.c - 1.1 arch/mips/kernel/genrtc.c - 1.1 arch/mips/jaguar-atx_defconfig - 1.1 arch/mips/gt64120/ev64120/setup.c - 1.1 arch/mips/gt64120/ev64120/serialGT.c - 1.1 arch/mips/gt64120/ev64120/reset.c - 1.1 arch/mips/gt64120/ev64120/promcon.c - 1.1 arch/mips/gt64120/ev64120/irq.c - 1.1 arch/mips/gt64120/ev64120/int-handler.S - 1.1 arch/mips/gt64120/ev64120/Makefile - 1.1 arch/mips/gt64120/common/time.c - 1.1 arch/mips/gt64120/common/pci.c - 1.1 arch/mips/galileo-boards/ev96100/reset.c - 1.1 arch/mips/dec/prom/console.c - 1.1 arch/mips/configs/yosemite_defconfig - 1.1 arch/mips/au1000/common/pci.c - 1.1 arch/mips/configs/xxs1500_defconfig - 1.1 arch/mips/configs/workpad_defconfig - 1.1 arch/mips/configs/tb0229_defconfig - 1.1 arch/mips/configs/tb0226_defconfig - 1.1 arch/mips/configs/sead_defconfig - 1.1 arch/mips/au1000/common/setup.c - 1.1 arch/mips/au1000/common/sleeper.S - 1.1 arch/mips/configs/sb1250-swarm_defconfig - 1.1 arch/mips/configs/rm200_defconfig - 1.1 arch/mips/au1000/csb250/Makefile - 1.1 arch/mips/au1000/csb250/board_setup.c - 1.1 arch/mips/au1000/csb250/init.c - 1.1 arch/mips/au1000/csb250/irqmap.c - 1.1 arch/mips/configs/pb1500_defconfig - 1.1 arch/mips/au1000/db1x00/board_setup.c - 1.1 arch/mips/configs/pb1100_defconfig - 1.1 arch/mips/au1000/db1x00/irqmap.c - 1.1 arch/mips/configs/pb1000_defconfig - 1.1 arch/mips/au1000/hydrogen3/Makefile - 1.1 arch/mips/au1000/hydrogen3/board_setup.c - 1.1 arch/mips/au1000/hydrogen3/init.c - 1.1 arch/mips/au1000/hydrogen3/irqmap.c - 1.1 arch/mips/au1000/mtx-1/Makefile - 1.1 arch/mips/au1000/mtx-1/board_setup.c - 1.1 arch/mips/au1000/mtx-1/init.c - 1.1 arch/mips/au1000/mtx-1/irqmap.c - 1.1 arch/mips/configs/osprey_defconfig - 1.1 arch/mips/au1000/pb1000/board_setup.c - 1.1 arch/mips/configs/ocelot_defconfig - 1.1 arch/mips/au1000/pb1000/irqmap.c - 1.1 arch/mips/configs/mtx1_defconfig - 1.1 arch/mips/configs/mpc30x_defconfig - 1.1 arch/mips/au1000/pb1100/board_setup.c - 1.1 arch/mips/configs/mirage_defconfig - 1.1 arch/mips/au1000/pb1100/irqmap.c - 1.1 arch/mips/configs/malta_defconfig - 1.1 arch/mips/configs/lasat200_defconfig - 1.1 arch/mips/au1000/pb1500/board_setup.c - 1.1 arch/mips/configs/jmr3927_defconfig - 1.1 arch/mips/au1000/pb1500/irqmap.c - 1.1 arch/mips/configs/jaguar-atx_defconfig - 1.1 arch/mips/au1000/pb1550/Makefile - 1.1 arch/mips/au1000/pb1550/board_setup.c - 1.1 arch/mips/au1000/pb1550/init.c - 1.1 arch/mips/au1000/pb1550/irqmap.c - 1.1 arch/mips/au1000/xxs1500/Makefile - 1.1 arch/mips/au1000/xxs1500/board_setup.c - 1.1 arch/mips/au1000/xxs1500/init.c - 1.1 arch/mips/au1000/xxs1500/irqmap.c - 1.1 arch/mips/configs/ivr_defconfig - 1.1 arch/mips/configs/it8172_defconfig - 1.1 arch/mips/configs/ip32_defconfig - 1.1 arch/mips/configs/ip27_defconfig - 1.1 arch/mips/configs/ip22_defconfig - 1.1 arch/mips/configs/hp-lj_defconfig - 1.1 arch/mips/configs/ev96100_defconfig - 1.1 arch/mips/configs/ev64120_defconfig - 1.1 arch/mips/configs/eagle_defconfig - 1.1 arch/mips/configs/atlas_defconfig - 1.1 arch/mips/configs/bosporus_defconfig - 1.1 arch/mips/configs/capcella_defconfig - 1.1 arch/mips/configs/cobalt_defconfig - 1.1 arch/mips/configs/db1000_defconfig - 1.1 arch/mips/configs/db1100_defconfig - 1.1 arch/mips/configs/db1500_defconfig - 1.1 arch/mips/configs/ddb5476_defconfig - 1.1 arch/mips/configs/ddb5477_defconfig - 1.1 arch/mips/configs/decstation_defconfig - 1.1 arch/mips/configs/e55_defconfig - 1.1 Documentation/00-INDEX - 1.2 Documentation/BK-usage/bk-make-sum - 1.2 Documentation/Changes - 1.4 Documentation/CodingStyle - 1.2 Documentation/DocBook/procfs_example.c - 1.2 Documentation/cdrom/ide-cd - 1.2 Documentation/computone.txt - 1.2 Documentation/crypto/api-intro.txt - 1.2 Documentation/digiboard.txt - 1.2 Documentation/fb/intel810.txt - 1.2 Documentation/filesystems/jfs.txt - 1.2 Documentation/filesystems/proc.txt - 1.2 Documentation/ftape.txt - 1.2 Documentation/hayes-esp.txt - 1.2 Documentation/ide.txt - 1.2 Documentation/ioctl-number.txt - 1.2 Documentation/kbuild/modules.txt - 1.3 Documentation/kernel-parameters.txt - 1.5 Documentation/networking/arcnet.txt - 1.2 Documentation/networking/baycom.txt - 1.2 Documentation/networking/bonding.txt - 1.3 Documentation/networking/dl2k.txt - 1.2 Documentation/networking/ifenslave.c - 1.3 Documentation/networking/ip-sysctl.txt - 1.5 Documentation/networking/ltpc.txt - 1.2 Documentation/networking/sk98lin.txt - 1.3 Documentation/networking/tuntap.txt - 1.2 Documentation/networking/vortex.txt - 1.2 Documentation/parport.txt - 1.2 Documentation/rocket.txt - 1.2 Documentation/s390/3270.txt - 1.2 Documentation/s390/CommonIO - 1.2 Documentation/s390/driver-model.txt - 1.3 Documentation/scsi/aic79xx.txt - 1.3 Documentation/scsi/aic7xxx.txt - 1.3 Documentation/scsi/osst.txt - 1.2 Documentation/scsi/st.txt - 1.3 Documentation/sonypi.txt - 1.2 Documentation/sound/oss/AWE32 - 1.2 Documentation/sound/oss/AudioExcelDSP16 - 1.2 Documentation/sound/oss/CMI8330 - 1.3 Documentation/sound/oss/Introduction - 1.3 Documentation/sound/oss/MAD16 - 1.2 Documentation/sound/oss/Maestro3 - 1.2 Documentation/sound/oss/OPL3-SA2 - 1.2 Documentation/sound/oss/Opti - 1.2 Documentation/sound/oss/PAS16 - 1.3 Documentation/sound/oss/README.modules - 1.2 Documentation/sound/oss/Wavefront - 1.3 Documentation/sysctl/fs.txt - 1.2 Documentation/usb/scanner.txt - 1.2 Documentation/video4linux/CQcam.txt - 1.2 Documentation/video4linux/Zoran - 1.2 Documentation/video4linux/bttv/Modules.conf - 1.2 Documentation/video4linux/bttv/README - 1.3 Documentation/video4linux/meye.txt - 1.2 Documentation/x86_64/boot-options.txt - 1.2 MAINTAINERS - 1.5 Makefile - 1.16 README - 1.3 arch/alpha/Kconfig - 1.3 arch/alpha/boot/misc.c - 1.2 arch/alpha/kernel/alpha_ksyms.c - 1.2 arch/alpha/kernel/irq.c - 1.3 arch/alpha/kernel/osf_sys.c - 1.2 arch/alpha/kernel/pci_iommu.c - 1.2 arch/alpha/kernel/proto.h - 1.2 arch/alpha/kernel/ptrace.c - 1.2 arch/alpha/kernel/semaphore.c - 1.2 arch/alpha/kernel/signal.c - 1.3 arch/alpha/kernel/systbls.S - 1.2 arch/alpha/kernel/time.c - 1.2 arch/alpha/lib/io.c - 1.2 arch/arm/Kconfig - 1.3 arch/arm/Makefile - 1.3 arch/arm/boot/compressed/head.S - 1.3 arch/arm/common/Makefile - 1.2 arch/arm/common/amba.c - 1.4 arch/arm/common/sa1111-pcibuf.c - 1.2 arch/arm/common/sa1111-pcipool.c - 1.2 arch/arm/common/sa1111.c - 1.3 arch/arm/kernel/Makefile - 1.2 arch/arm/kernel/armksyms.c - 1.3 arch/arm/kernel/asm-offsets.c - 1.3 arch/arm/kernel/entry-header.S - 1.2 arch/arm/kernel/irq.c - 1.3 arch/arm/kernel/pm.c - 1.2 arch/arm/kernel/setup.c - 1.3 arch/arm/kernel/sys_arm.c - 1.2 arch/arm/kernel/time.c - 1.3 arch/arm/lib/io-readsl-armv4.S - 1.2 arch/arm/mach-integrator/integrator_ap.c - 1.4 arch/arm/mach-sa1100/generic.c - 1.4 arch/arm/mach-sa1100/irq.c - 1.2 arch/arm/mm/Kconfig - 1.3 arch/arm/mm/Makefile - 1.2 arch/arm/mm/abort-lv4t.S - 1.2 arch/arm/mm/mm-armv.c - 1.3 arch/arm/mm/proc-macros.S - 1.2 arch/arm/nwfpe/fpmodule.c - 1.2 arch/arm/tools/mach-types - 1.2 arch/arm26/Kconfig - 1.2 arch/arm26/kernel/armksyms.c - 1.2 arch/arm26/kernel/sys_arm.c - 1.2 arch/arm26/kernel/time.c - 1.2 arch/arm26/mm/Makefile - 1.2 arch/cris/arch-v10/drivers/ethernet.c - 1.2 arch/cris/kernel/sys_cris.c - 1.2 arch/cris/kernel/time.c - 1.2 arch/h8300/Kconfig - 1.3 arch/h8300/defconfig - 1.2 arch/h8300/kernel/signal.c - 1.2 arch/h8300/kernel/sys_h8300.c - 1.2 arch/h8300/kernel/time.c - 1.2 arch/h8300/mm/Makefile - 1.3 arch/h8300/platform/h8300h/Makefile - 1.2 arch/h8300/platform/h8300h/aki3068net/Makefile - 1.2 arch/h8300/platform/h8300h/aki3068net/timer.c - 1.2 arch/h8300/platform/h8300h/entry.S - 1.2 arch/h8300/platform/h8300h/generic/Makefile - 1.2 arch/h8300/platform/h8300h/generic/crt0_rom.S - 1.2 arch/h8300/platform/h8300h/generic/timer.c - 1.2 arch/h8300/platform/h8300h/h8max/Makefile - 1.2 arch/h8300/platform/h8300h/h8max/timer.c - 1.2 arch/h8300/platform/h8s/Makefile - 1.2 arch/h8300/platform/h8s/edosk2674/Makefile - 1.2 arch/h8300/platform/h8s/edosk2674/crt0_rom.S - 1.2 arch/h8300/platform/h8s/edosk2674/timer.c - 1.2 arch/h8300/platform/h8s/entry.S - 1.2 arch/h8300/platform/h8s/generic/Makefile - 1.2 arch/h8300/platform/h8s/generic/crt0_rom.S - 1.2 arch/h8300/platform/h8s/generic/timer.c - 1.2 arch/i386/Kconfig - 1.8 arch/i386/Makefile - 1.5 arch/i386/boot/Makefile - 1.2 arch/i386/boot/setup.S - 1.4 arch/i386/defconfig - 1.5 arch/i386/kernel/Makefile - 1.3 arch/i386/kernel/acpi/boot.c - 1.7 arch/i386/kernel/apic.c - 1.3 arch/i386/kernel/bootflag.c - 1.2 arch/i386/kernel/cpu/centaur.c - 1.2 arch/i386/kernel/cpu/cpufreq/Kconfig - 1.3 arch/i386/kernel/cpu/cpufreq/elanfreq.c - 1.2 arch/i386/kernel/cpu/cpufreq/longhaul.c - 1.4 arch/i386/kernel/cpu/cpufreq/longrun.c - 1.2 arch/i386/kernel/cpu/cpufreq/powernow-k6.c - 1.2 arch/i386/kernel/cpu/cpufreq/powernow-k7.c - 1.4 arch/i386/kernel/cpu/cpufreq/powernow-k8.c - 1.4 arch/i386/kernel/cpu/cpufreq/speedstep-ich.c - 1.2 arch/i386/kernel/cpu/cpufreq/speedstep-smi.c - 1.3 arch/i386/kernel/cpu/intel.c - 1.4 arch/i386/kernel/cpu/mcheck/non-fatal.c - 1.3 arch/i386/kernel/cpu/mtrr/generic.c - 1.2 arch/i386/kernel/cpu/mtrr/main.c - 1.2 arch/i386/kernel/cpu/proc.c - 1.2 arch/i386/kernel/edd.c - 1.3 arch/i386/kernel/entry.S - 1.5 arch/i386/kernel/head.S - 1.2 arch/i386/kernel/i8259.c - 1.6 arch/i386/kernel/io_apic.c - 1.7 arch/i386/kernel/irq.c - 1.3 arch/i386/kernel/microcode.c - 1.2 arch/i386/kernel/mpparse.c - 1.6 arch/i386/kernel/nmi.c - 1.5 arch/i386/kernel/process.c - 1.4 arch/i386/kernel/semaphore.c - 1.2 arch/i386/kernel/setup.c - 1.5 arch/i386/kernel/signal.c - 1.2 arch/i386/kernel/smp.c - 1.5 arch/i386/kernel/smpboot.c - 1.6 arch/i386/kernel/sys_i386.c - 1.2 arch/i386/kernel/time.c - 1.4 arch/i386/kernel/timers/Makefile - 1.2 arch/i386/kernel/timers/common.c - 1.2 arch/i386/kernel/timers/timer.c - 1.2 arch/i386/kernel/timers/timer_cyclone.c - 1.3 arch/i386/kernel/traps.c - 1.5 arch/i386/kernel/vm86.c - 1.3 arch/i386/mach-voyager/Makefile - 1.2 arch/i386/math-emu/errors.c - 1.2 arch/i386/math-emu/fpu_proto.h - 1.2 arch/i386/mm/extable.c - 1.3 arch/i386/oprofile/nmi_int.c - 1.2 arch/i386/oprofile/nmi_timer_int.c - 1.2 arch/i386/oprofile/op_model_ppro.c - 1.2 arch/i386/pci/Makefile - 1.2 arch/i386/pci/common.c - 1.3 arch/i386/pci/fixup.c - 1.2 arch/i386/pci/irq.c - 1.4 arch/i386/pci/pci.h - 1.3 arch/ia64/Kconfig - 1.5 arch/ia64/Makefile - 1.4 arch/ia64/defconfig - 1.5 arch/ia64/hp/sim/simeth.c - 1.2 arch/ia64/ia32/binfmt_elf32.c - 1.3 arch/ia64/ia32/ia32_ioctl.c - 1.2 arch/ia64/ia32/ia32_signal.c - 1.2 arch/ia64/ia32/sys_ia32.c - 1.4 arch/ia64/kernel/Makefile - 1.3 arch/ia64/kernel/acpi.c - 1.7 arch/ia64/kernel/head.S - 1.3 arch/ia64/kernel/iosapic.c - 1.4 arch/ia64/kernel/irq.c - 1.5 arch/ia64/kernel/irq_ia64.c - 1.3 arch/ia64/kernel/ivt.S - 1.3 arch/ia64/kernel/perfmon.c - 1.4 arch/ia64/kernel/perfmon_default_smpl.c - 1.3 arch/ia64/kernel/process.c - 1.3 arch/ia64/kernel/ptrace.c - 1.3 arch/ia64/kernel/sal.c - 1.2 arch/ia64/kernel/signal.c - 1.3 arch/ia64/kernel/sys_ia64.c - 1.2 arch/ia64/kernel/unwind.c - 1.4 arch/ia64/mm/discontig.c - 1.4 arch/ia64/mm/hugetlbpage.c - 1.3 arch/ia64/mm/init.c - 1.4 arch/ia64/pci/pci.c - 1.4 arch/ia64/sn/io/drivers/ioconfig_bus.c - 1.3 arch/ia64/sn/io/io.c - 1.4 arch/ia64/sn/io/machvec/pci_bus_cvlink.c - 1.4 arch/ia64/sn/io/machvec/pci_dma.c - 1.4 arch/ia64/sn/io/sn2/bte_error.c - 1.3 arch/ia64/sn/io/sn2/geo_op.c - 1.3 arch/ia64/sn/io/sn2/klconflib.c - 1.4 arch/ia64/sn/io/sn2/ml_SN_init.c - 1.3 arch/ia64/sn/io/sn2/ml_SN_intr.c - 1.3 arch/ia64/sn/io/sn2/pcibr/pcibr_ate.c - 1.4 arch/ia64/sn/io/sn2/pcibr/pcibr_config.c - 1.4 arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c - 1.4 arch/ia64/sn/io/sn2/pcibr/pcibr_intr.c - 1.4 arch/ia64/sn/io/sn2/pcibr/pcibr_rrb.c - 1.4 arch/ia64/sn/io/sn2/pcibr/pcibr_slot.c - 1.4 arch/ia64/sn/io/sn2/pic.c - 1.4 arch/ia64/sn/io/sn2/shub.c - 1.3 arch/ia64/sn/io/sn2/shub_intr.c - 1.3 arch/ia64/sn/io/sn2/shuberror.c - 1.4 arch/ia64/sn/io/xswitch.c - 1.4 arch/ia64/sn/kernel/irq.c - 1.4 arch/ia64/sn/kernel/setup.c - 1.5 arch/m68k/Kconfig - 1.4 arch/m68k/Makefile - 1.2 arch/m68k/atari/config.c - 1.2 arch/m68k/fpsp040/skeleton.S - 1.2 arch/m68k/ifpsp060/iskeleton.S - 1.2 arch/m68k/kernel/Makefile - 1.2 arch/m68k/kernel/entry.S - 1.2 arch/m68k/kernel/head.S - 1.3 arch/m68k/kernel/m68k_defs.c - 1.2 arch/m68k/kernel/m68k_defs.head - 1.2 arch/m68k/kernel/module.c - 1.2 arch/m68k/kernel/setup.c - 1.2 arch/m68k/kernel/signal.c - 1.2 arch/m68k/kernel/sys_m68k.c - 1.2 arch/m68k/kernel/time.c - 1.2 arch/m68k/kernel/traps.c - 1.3 arch/m68k/mac/iop.c - 1.2 arch/m68k/mac/macints.c - 1.2 arch/m68k/mac/via.c - 1.2 arch/m68k/math-emu/fp_emu.h - 1.2 arch/m68k/mm/Makefile - 1.3 arch/m68k/mm/init.c - 1.2 arch/m68k/sun3/config.c - 1.2 arch/m68knommu/Kconfig - 1.2 arch/m68knommu/defconfig - 1.2 arch/m68knommu/kernel/signal.c - 1.2 arch/m68knommu/kernel/sys_m68k.c - 1.2 arch/m68knommu/kernel/time.c - 1.3 arch/m68knommu/platform/5407/MOTOROLA/crt0_ram.S - 1.2 arch/mips/Kconfig - 1.4 arch/mips/Makefile - 1.2 arch/mips/arc/cmdline.c - 1.2 arch/mips/arc/identify.c - 1.2 arch/mips/arc/init.c - 1.2 arch/mips/arc/memory.c - 1.2 arch/mips/arc/misc.c - 1.2 arch/mips/au1000/common/Makefile - 1.2 arch/mips/au1000/common/clocks.c - 1.2 arch/mips/au1000/common/dbg_io.c - 1.2 arch/mips/au1000/common/dma.c - 1.2 arch/mips/au1000/common/irq.c - 1.2 arch/mips/au1000/common/power.c - 1.2 arch/mips/au1000/common/prom.c - 1.2 arch/mips/au1000/common/puts.c - 1.2 arch/mips/au1000/common/reset.c - 1.2 arch/mips/au1000/common/rtc.c - 1.2 arch/mips/au1000/common/time.c - 1.2 arch/mips/au1000/common/usbdev.c - 1.2 arch/mips/au1000/db1x00/Makefile - 1.2 arch/mips/au1000/db1x00/init.c - 1.2 arch/mips/au1000/db1x00/setup.c - 1.2 arch/mips/au1000/pb1000/Makefile - 1.2 arch/mips/au1000/pb1000/init.c - 1.2 arch/mips/au1000/pb1000/setup.c - 1.2 arch/mips/au1000/pb1100/Makefile - 1.2 arch/mips/au1000/pb1100/init.c - 1.2 arch/mips/au1000/pb1100/setup.c - 1.2 arch/mips/au1000/pb1500/Makefile - 1.2 arch/mips/au1000/pb1500/init.c - 1.2 arch/mips/au1000/pb1500/setup.c - 1.2 arch/mips/baget/prom/init.c - 1.2 arch/mips/baget/setup.c - 1.2 arch/mips/boot/Makefile - 1.2 arch/mips/cobalt/Makefile - 1.2 arch/mips/cobalt/int-handler.S - 1.2 arch/mips/cobalt/irq.c - 1.2 arch/mips/cobalt/promcon.c - 1.2 arch/mips/cobalt/setup.c - 1.2 arch/mips/cobalt/via.c - 1.2 arch/mips/ddb5xxx/common/prom.c - 1.2 arch/mips/ddb5xxx/ddb5074/Makefile - 1.2 arch/mips/ddb5xxx/ddb5074/nile4_pic.c - 1.2 arch/mips/ddb5xxx/ddb5074/setup.c - 1.2 arch/mips/ddb5xxx/ddb5074/time.c - 1.2 arch/mips/ddb5xxx/ddb5476/setup.c - 1.2 arch/mips/ddb5xxx/ddb5477/setup.c - 1.2 arch/mips/dec/Makefile - 1.2 arch/mips/dec/ecc-berr.c - 1.2 arch/mips/dec/int-handler.S - 1.2 arch/mips/dec/prom/Makefile - 1.2 arch/mips/dec/prom/cmdline.c - 1.2 arch/mips/dec/prom/identify.c - 1.2 arch/mips/dec/prom/init.c - 1.2 arch/mips/dec/prom/memory.c - 1.2 arch/mips/dec/promcon.c - 1.2 arch/mips/dec/reset.c - 1.2 arch/mips/dec/rtc-dec.c - 1.2 arch/mips/dec/setup.c - 1.2 arch/mips/dec/time.c - 1.2 arch/mips/defconfig - 1.2 arch/mips/defconfig-atlas - 1.2 arch/mips/defconfig-capcella - 1.2 arch/mips/defconfig-cobalt - 1.2 arch/mips/defconfig-ddb5476 - 1.2 arch/mips/defconfig-ddb5477 - 1.2 arch/mips/defconfig-decstation - 1.2 arch/mips/defconfig-e55 - 1.2 arch/mips/defconfig-eagle - 1.2 arch/mips/defconfig-ev64120 - 1.2 arch/mips/defconfig-ev96100 - 1.2 arch/mips/defconfig-hp-lj - 1.2 arch/mips/defconfig-ip22 - 1.2 arch/mips/defconfig-ip27 - 1.2 arch/mips/defconfig-ip32 - 1.2 arch/mips/defconfig-it8172 - 1.2 arch/mips/defconfig-ivr - 1.2 arch/mips/defconfig-jmr3927 - 1.2 arch/mips/defconfig-lasat200 - 1.3 arch/mips/defconfig-malta - 1.2 arch/mips/defconfig-mpc30x - 1.2 arch/mips/defconfig-ocelot - 1.2 arch/mips/defconfig-osprey - 1.2 arch/mips/defconfig-pb1000 - 1.2 arch/mips/defconfig-pb1100 - 1.2 arch/mips/defconfig-pb1500 - 1.2 arch/mips/defconfig-rm200 - 1.2 arch/mips/defconfig-sb1250-swarm - 1.2 arch/mips/defconfig-sead - 1.2 arch/mips/defconfig-tb0226 - 1.2 arch/mips/defconfig-tb0229 - 1.2 arch/mips/defconfig-workpad - 1.2 arch/mips/galileo-boards/ev64120/Makefile - 1.2 arch/mips/galileo-boards/ev64120/README - 1.2 arch/mips/galileo-boards/ev64120/dma.c - 1.2 arch/mips/galileo-boards/ev64120/i2o.c - 1.2 arch/mips/galileo-boards/ev64120/int-handler.S - 1.2 arch/mips/galileo-boards/ev64120/irq-handler.c - 1.2 arch/mips/galileo-boards/ev64120/irq.c - 1.2 arch/mips/galileo-boards/ev64120/promcon.c - 1.2 arch/mips/galileo-boards/ev64120/reset.c - 1.2 arch/mips/galileo-boards/ev64120/serialGT.c - 1.2 arch/mips/galileo-boards/ev64120/setup.c - 1.2 arch/mips/galileo-boards/ev96100/Makefile - 1.2 arch/mips/galileo-boards/ev96100/init.c - 1.2 arch/mips/galileo-boards/ev96100/int-handler.S - 1.2 arch/mips/galileo-boards/ev96100/irq.c - 1.2 arch/mips/galileo-boards/ev96100/puts.c - 1.2 arch/mips/galileo-boards/ev96100/setup.c - 1.2 arch/mips/galileo-boards/ev96100/time.c - 1.2 arch/mips/galileo-boards/generic/Makefile - 1.2 arch/mips/galileo-boards/generic/reset.c - 1.2 arch/mips/gt64120/common/Makefile - 1.2 arch/mips/gt64120/common/gt_irq.c - 1.2 arch/mips/gt64120/momenco_ocelot/irq.c - 1.2 arch/mips/gt64120/momenco_ocelot/prom.c - 1.2 arch/mips/gt64120/momenco_ocelot/setup.c - 1.2 arch/mips/hp-lj/init.c - 1.2 arch/mips/hp-lj/setup.c - 1.2 arch/mips/ite-boards/generic/irq.c - 1.2 arch/mips/ite-boards/generic/it8172_setup.c - 1.2 arch/mips/ite-boards/generic/pmon_prom.c - 1.2 arch/mips/ite-boards/generic/time.c - 1.2 arch/mips/ite-boards/ivr/init.c - 1.2 arch/mips/ite-boards/qed-4n-s01b/Makefile - 1.2 arch/mips/ite-boards/qed-4n-s01b/init.c - 1.2 arch/mips/jazz/Makefile - 1.2 arch/mips/jazz/floppy-jazz.c - 1.2 arch/mips/jazz/int-handler.S - 1.2 arch/mips/jazz/irq.c - 1.2 arch/mips/jazz/jazz-ksyms.c - 1.2 arch/mips/jazz/jazzdma.c - 1.2 arch/mips/jazz/kbd-jazz.c - 1.2 arch/mips/jazz/reset.c - 1.2 arch/mips/jazz/rtc-jazz.c - 1.2 arch/mips/jazz/setup.c - 1.2 arch/mips/jmr3927/common/prom.c - 1.2 arch/mips/jmr3927/rbhma3100/Makefile - 1.2 arch/mips/jmr3927/rbhma3100/init.c - 1.2 arch/mips/jmr3927/rbhma3100/irq.c - 1.2 arch/mips/jmr3927/rbhma3100/rtc.c - 1.2 arch/mips/jmr3927/rbhma3100/setup.c - 1.2 arch/mips/kernel/Makefile - 1.2 arch/mips/kernel/binfmt_elfn32.c - 1.2 arch/mips/kernel/binfmt_elfo32.c - 1.2 arch/mips/kernel/branch.c - 1.2 arch/mips/kernel/cpu-bugs64.c - 1.2 arch/mips/kernel/cpu-probe.c - 1.2 arch/mips/kernel/entry.S - 1.2 arch/mips/kernel/gdb-low.S - 1.2 arch/mips/kernel/gdb-stub.c - 1.2 arch/mips/kernel/genex.S - 1.2 arch/mips/kernel/head.S - 1.2 arch/mips/kernel/i8259.c - 1.2 arch/mips/kernel/init_task.c - 1.2 arch/mips/kernel/ioctl32.c - 1.2 arch/mips/kernel/irixioctl.c - 1.2 arch/mips/kernel/irixsig.c - 1.2 arch/mips/kernel/irq.c - 1.3 arch/mips/kernel/irq_cpu.c - 1.2 arch/mips/kernel/linux32.c - 1.2 arch/mips/kernel/mips_ksyms.c - 1.2 arch/mips/kernel/module-elf32.c - 1.2 arch/mips/kernel/module-elf64.c - 1.2 arch/mips/kernel/offset.c - 1.2 arch/mips/kernel/pci-dma.c - 1.2 arch/mips/kernel/proc.c - 1.2 arch/mips/kernel/process.c - 1.2 arch/mips/kernel/ptrace.c - 1.2 arch/mips/kernel/ptrace32.c - 1.2 arch/mips/kernel/r2300_switch.S - 1.2 arch/mips/kernel/r4k_fpu.S - 1.2 arch/mips/kernel/r4k_switch.S - 1.2 arch/mips/kernel/scall32-o32.S - 1.2 arch/mips/kernel/scall64-64.S - 1.2 arch/mips/kernel/scall64-n32.S - 1.2 arch/mips/kernel/scall64-o32.S - 1.2 arch/mips/kernel/semaphore.c - 1.2 arch/mips/kernel/setup.c - 1.2 arch/mips/kernel/signal.c - 1.2 arch/mips/kernel/signal32.c - 1.2 arch/mips/kernel/signal_n32.c - 1.2 arch/mips/kernel/smp.c - 1.2 arch/mips/kernel/syscall.c - 1.2 arch/mips/kernel/sysirix.c - 1.2 arch/mips/kernel/time.c - 1.2 arch/mips/kernel/traps.c - 1.2 arch/mips/kernel/unaligned.c - 1.2 arch/mips/kernel/vmlinux.lds.S - 1.2 arch/mips/lasat/Makefile - 1.2 arch/mips/lasat/interrupt.c - 1.2 arch/mips/lasat/lasatIRQ.S - 1.2 arch/mips/lasat/lasat_board.c - 1.2 arch/mips/lasat/prom.c - 1.2 arch/mips/lasat/reset.c - 1.2 arch/mips/lasat/setup.c - 1.2 arch/mips/lib-32/Makefile - 1.2 arch/mips/lib-32/csum_partial.S - 1.2 arch/mips/lib-32/dump_tlb.c - 1.2 arch/mips/lib-32/r3k_dump_tlb.c - 1.2 arch/mips/lib-32/strlen_user.S - 1.2 arch/mips/lib-32/strncpy_user.S - 1.2 arch/mips/lib-32/strnlen_user.S - 1.2 arch/mips/lib-64/Makefile - 1.2 arch/mips/lib-64/dump_tlb.c - 1.2 arch/mips/lib-64/strlen_user.S - 1.2 arch/mips/lib-64/strncpy_user.S - 1.2 arch/mips/lib-64/strnlen_user.S - 1.2 arch/mips/lib/Makefile - 1.2 arch/mips/lib/floppy-no.c - 1.2 arch/mips/lib/floppy-std.c - 1.2 arch/mips/lib/ide-no.c - 1.2 arch/mips/lib/ide-std.c - 1.2 arch/mips/lib/rtc-no.c - 1.2 arch/mips/lib/rtc-std.c - 1.2 arch/mips/math-emu/cp1emu.c - 1.2 arch/mips/math-emu/dp_fint.c - 1.2 arch/mips/math-emu/dp_flong.c - 1.2 arch/mips/math-emu/kernel_linkage.c - 1.2 arch/mips/math-emu/sp_fint.c - 1.2 arch/mips/math-emu/sp_flong.c - 1.2 arch/mips/mips-boards/atlas/Makefile - 1.2 arch/mips/mips-boards/atlas/atlas_int.c - 1.2 arch/mips/mips-boards/atlas/atlas_rtc.c - 1.2 arch/mips/mips-boards/atlas/atlas_setup.c - 1.2 arch/mips/mips-boards/generic/Makefile - 1.2 arch/mips/mips-boards/generic/cmdline.c - 1.2 arch/mips/mips-boards/generic/display.c - 1.2 arch/mips/mips-boards/generic/gdb_hook.c - 1.2 arch/mips/mips-boards/generic/init.c - 1.2 arch/mips/mips-boards/generic/memory.c - 1.2 arch/mips/mips-boards/generic/printf.c - 1.2 arch/mips/mips-boards/generic/reset.c - 1.2 arch/mips/mips-boards/generic/time.c - 1.2 arch/mips/mips-boards/malta/Makefile - 1.2 arch/mips/mips-boards/malta/malta_int.c - 1.2 arch/mips/mips-boards/malta/malta_rtc.c - 1.2 arch/mips/mips-boards/malta/malta_setup.c - 1.2 arch/mips/mips-boards/sead/Makefile - 1.2 arch/mips/mips-boards/sead/sead_int.c - 1.2 arch/mips/mips-boards/sead/sead_setup.c - 1.2 arch/mips/mips-boards/sead/sead_time.c - 1.2 arch/mips/mm-32/Makefile - 1.2 arch/mips/mm-32/init.c - 1.2 arch/mips/mm-32/pg-r4k.S - 1.2 arch/mips/mm-32/tlbex-r4k.S - 1.2 arch/mips/mm-64/Makefile - 1.2 arch/mips/mm-64/init.c - 1.2 arch/mips/mm-64/pg-r4k.c - 1.2 arch/mips/mm-64/tlbex-r4k.S - 1.2 arch/mips/mm/Makefile - 1.3 arch/mips/mm/c-r3k.c - 1.2 arch/mips/mm/c-r4k.c - 1.2 arch/mips/mm/c-sb1.c - 1.2 arch/mips/mm/c-tx39.c - 1.2 arch/mips/mm/cache.c - 1.2 arch/mips/mm/cerr-sb1.c - 1.2 arch/mips/mm/cex-sb1.S - 1.2 arch/mips/mm/extable.c - 1.3 arch/mips/mm/fault.c - 1.2 arch/mips/mm/highmem.c - 1.3 arch/mips/mm/loadmmu.c - 1.2 arch/mips/mm/pg-r3k.c - 1.2 arch/mips/mm/pg-sb1.c - 1.2 arch/mips/mm/pgtable-32.c - 1.2 arch/mips/mm/pgtable-64.c - 1.2 arch/mips/mm/pgtable.c - 1.2 arch/mips/mm/sc-r5k.c - 1.2 arch/mips/mm/sc-rm7k.c - 1.2 arch/mips/mm/tlb-andes.c - 1.2 arch/mips/mm/tlb-r3k.c - 1.2 arch/mips/mm/tlb-r4k.c - 1.2 arch/mips/mm/tlb-sb1.c - 1.2 arch/mips/mm/tlbex-r3k.S - 1.2 arch/mips/momentum/ocelot_c/cpci-irq.c - 1.2 arch/mips/momentum/ocelot_c/int-handler.S - 1.2 arch/mips/momentum/ocelot_c/irq.c - 1.2 arch/mips/momentum/ocelot_c/mv-irq.c - 1.2 arch/mips/momentum/ocelot_c/ocelot_c_fpga.h - 1.2 arch/mips/momentum/ocelot_c/pci-irq.c - 1.2 arch/mips/momentum/ocelot_c/prom.c - 1.2 arch/mips/momentum/ocelot_c/reset.c - 1.2 arch/mips/momentum/ocelot_c/setup.c - 1.2 arch/mips/momentum/ocelot_c/uart-irq.c - 1.2 arch/mips/momentum/ocelot_g/gt-irq.c - 1.2 arch/mips/momentum/ocelot_g/int-handler.S - 1.2 arch/mips/momentum/ocelot_g/irq.c - 1.2 arch/mips/momentum/ocelot_g/pci-irq.c - 1.2 arch/mips/momentum/ocelot_g/prom.c - 1.2 arch/mips/momentum/ocelot_g/setup.c - 1.2 arch/mips/pci/Makefile - 1.2 arch/mips/pci/common.c - 1.2 arch/mips/pci/fixup-au1000.c - 1.2 arch/mips/pci/fixup-capcella.c - 1.2 arch/mips/pci/fixup-eagle.c - 1.2 arch/mips/pci/fixup-ite8172g.c - 1.2 arch/mips/pci/fixup-ivr.c - 1.2 arch/mips/pci/fixup-jmr3927.c - 1.2 arch/mips/pci/fixup-ocelot.c - 1.2 arch/mips/pci/fixup-tb0226.c - 1.2 arch/mips/pci/fixup-tb0229.c - 1.2 arch/mips/pci/fixup-victor-mpc30x.c - 1.2 arch/mips/pci/fixups-ev96100.c - 1.2 arch/mips/pci/ops-au1000.c - 1.2 arch/mips/pci/ops-ddb5074.c - 1.2 arch/mips/pci/ops-ddb5476.c - 1.2 arch/mips/pci/ops-ddb5477.c - 1.2 arch/mips/pci/ops-ev64120.c - 1.2 arch/mips/pci/ops-ev96100.c - 1.2 arch/mips/pci/ops-it8172.c - 1.2 arch/mips/pci/ops-jmr3927.c - 1.2 arch/mips/pci/ops-ocelot.c - 1.2 arch/mips/pci/pci-auto.c - 1.2 arch/mips/pci/pci-cobalt.c - 1.2 arch/mips/pci/pci-ddb5074.c - 1.2 arch/mips/pci/pci-ddb5476.c - 1.2 arch/mips/pci/pci-ddb5477.c - 1.2 arch/mips/pci/pci-hplj.c - 1.2 arch/mips/pci/pci-ip27.c - 1.2 arch/mips/pci/pci-ip32.c - 1.2 arch/mips/pci/pci-lasat.c - 1.2 arch/mips/pci/pci-mips.c - 1.2 arch/mips/pci/pci-ocelot-c.c - 1.2 arch/mips/pci/pci-ocelot-g.c - 1.2 arch/mips/pci/pci-sb1250.c - 1.2 arch/mips/pci/pci-sni.c - 1.2 arch/mips/pci/pci-vr41xx.c - 1.2 arch/mips/pci/pci-vr41xx.h - 1.2 arch/mips/pci/pci.c - 1.2 arch/mips/ramdisk/Makefile - 1.2 arch/mips/sgi-ip22/Makefile - 1.2 arch/mips/sgi-ip22/ip22-berr.c - 1.2 arch/mips/sgi-ip22/ip22-hpc.c - 1.2 arch/mips/sgi-ip22/ip22-int.c - 1.2 arch/mips/sgi-ip22/ip22-ksyms.c - 1.2 arch/mips/sgi-ip22/ip22-mc.c - 1.2 arch/mips/sgi-ip22/ip22-nvram.c - 1.2 arch/mips/sgi-ip22/ip22-reset.c - 1.2 arch/mips/sgi-ip22/ip22-rtc.c - 1.2 arch/mips/sgi-ip22/ip22-setup.c - 1.2 arch/mips/sgi-ip22/ip22-time.c - 1.2 arch/mips/sgi-ip27/Makefile - 1.2 arch/mips/sgi-ip27/ip27-console.c - 1.2 arch/mips/sgi-ip27/ip27-init.c - 1.2 arch/mips/sgi-ip27/ip27-irq-glue.S - 1.2 arch/mips/sgi-ip27/ip27-irq.c - 1.2 arch/mips/sgi-ip27/ip27-klnuma.c - 1.2 arch/mips/sgi-ip27/ip27-memory.c - 1.2 arch/mips/sgi-ip27/ip27-nmi.c - 1.2 arch/mips/sgi-ip27/ip27-setup.c - 1.2 arch/mips/sgi-ip27/ip27-timer.c - 1.2 arch/mips/sgi-ip32/Makefile - 1.2 arch/mips/sgi-ip32/crime.c - 1.2 arch/mips/sgi-ip32/ip32-irq-glue.S - 1.2 arch/mips/sgi-ip32/ip32-irq.c - 1.2 arch/mips/sgi-ip32/ip32-reset.c - 1.2 arch/mips/sgi-ip32/ip32-rtc.c - 1.2 arch/mips/sgi-ip32/ip32-setup.c - 1.2 arch/mips/sgi-ip32/ip32-timer.c - 1.2 arch/mips/sibyte/cfe/console.c - 1.2 arch/mips/sibyte/cfe/setup.c - 1.2 arch/mips/sibyte/cfe/smp.c - 1.2 arch/mips/sibyte/sb1250/bcm1250_tbprof.c - 1.2 arch/mips/sibyte/sb1250/bus_watcher.c - 1.2 arch/mips/sibyte/sb1250/irq.c - 1.2 arch/mips/sibyte/sb1250/irq_handler.S - 1.2 arch/mips/sibyte/sb1250/prom.c - 1.2 arch/mips/sibyte/sb1250/setup.c - 1.2 arch/mips/sibyte/sb1250/smp.c - 1.2 arch/mips/sibyte/sb1250/time.c - 1.2 arch/mips/sibyte/swarm/Makefile - 1.2 arch/mips/sibyte/swarm/cmdline.c - 1.2 arch/mips/sibyte/swarm/dbg_io.c - 1.2 arch/mips/sibyte/swarm/rtc.c - 1.2 arch/mips/sibyte/swarm/rtc_m41t81.c - 1.2 arch/mips/sibyte/swarm/rtc_xicor1241.c - 1.2 arch/mips/sibyte/swarm/setup.c - 1.2 arch/mips/sibyte/swarm/time.c - 1.2 arch/mips/sni/Makefile - 1.2 arch/mips/sni/int-handler.S - 1.2 arch/mips/sni/io.c - 1.2 arch/mips/sni/irq.c - 1.2 arch/mips/sni/setup.c - 1.2 arch/mips/tx4927/common/Makefile - 1.2 arch/mips/tx4927/common/tx4927_irq.c - 1.2 arch/mips/tx4927/common/tx4927_irq_handler.S - 1.2 arch/mips/tx4927/common/tx4927_setup.c - 1.2 arch/mips/tx4927/toshiba_rbtx4927/Makefile - 1.2 arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c - 1.2 arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_pci_fixup.c - 1.2 arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_pci_ops.c - 1.2 arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_prom.c - 1.2 arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c - 1.2 arch/mips/vr4181/osprey/prom.c - 1.2 arch/mips/vr4181/osprey/setup.c - 1.2 arch/mips/vr41xx/casio-e55/Makefile - 1.2 arch/mips/vr41xx/casio-e55/ide-e55.c - 1.2 arch/mips/vr41xx/casio-e55/init.c - 1.2 arch/mips/vr41xx/casio-e55/setup.c - 1.2 arch/mips/vr41xx/common/Makefile - 1.2 arch/mips/vr41xx/common/bcu.c - 1.2 arch/mips/vr41xx/common/cmu.c - 1.2 arch/mips/vr41xx/common/giu.c - 1.2 arch/mips/vr41xx/common/icu.c - 1.2 arch/mips/vr41xx/common/int-handler.S - 1.2 arch/mips/vr41xx/common/reset.c - 1.2 arch/mips/vr41xx/common/serial.c - 1.2 arch/mips/vr41xx/common/time.c - 1.2 arch/mips/vr41xx/common/vrc4173.c - 1.2 arch/mips/vr41xx/ibm-workpad/Makefile - 1.2 arch/mips/vr41xx/ibm-workpad/ide-workpad.c - 1.2 arch/mips/vr41xx/ibm-workpad/init.c - 1.2 arch/mips/vr41xx/ibm-workpad/setup.c - 1.2 arch/mips/vr41xx/nec-eagle/Makefile - 1.2 arch/mips/vr41xx/nec-eagle/ide-eagle.c - 1.2 arch/mips/vr41xx/nec-eagle/init.c - 1.2 arch/mips/vr41xx/nec-eagle/setup.c - 1.2 arch/mips/vr41xx/tanbac-tb0226/init.c - 1.2 arch/mips/vr41xx/tanbac-tb0226/setup.c - 1.2 arch/mips/vr41xx/tanbac-tb0229/Makefile - 1.2 arch/mips/vr41xx/tanbac-tb0229/init.c - 1.2 arch/mips/vr41xx/tanbac-tb0229/reboot.c - 1.2 arch/mips/vr41xx/tanbac-tb0229/setup.c - 1.2 arch/mips/vr41xx/victor-mpc30x/Makefile - 1.2 arch/mips/vr41xx/victor-mpc30x/ide-mpc30x.c - 1.2 arch/mips/vr41xx/victor-mpc30x/init.c - 1.2 arch/mips/vr41xx/victor-mpc30x/setup.c - 1.2 arch/mips/vr41xx/zao-capcella/Makefile - 1.2 arch/mips/vr41xx/zao-capcella/ide-capcella.c - 1.2 arch/mips/vr41xx/zao-capcella/init.c - 1.2 arch/mips/vr41xx/zao-capcella/setup.c - 1.2 arch/parisc/hpux/ioctl.c - 1.3 arch/parisc/hpux/sys_hpux.c - 1.3 arch/parisc/kernel/ioctl32.c - 1.3 arch/parisc/kernel/parisc_ksyms.c - 1.4 arch/parisc/kernel/signal32.c - 1.4 arch/parisc/kernel/sys_parisc.c - 1.5 arch/parisc/kernel/sys_parisc32.c - 1.3 arch/parisc/kernel/time.c - 1.3 arch/ppc/8260_io/enet.c - 1.2 arch/ppc/8260_io/fcc_enet.c - 1.2 arch/ppc/8xx_io/enet.c - 1.2 arch/ppc/8xx_io/fec.c - 1.2 arch/ppc/Kconfig - 1.5 arch/ppc/kernel/head.S - 1.4 arch/ppc/kernel/irq.c - 1.3 arch/ppc/kernel/l2cr.S - 1.2 arch/ppc/kernel/setup.c - 1.4 arch/ppc/kernel/smp.c - 1.3 arch/ppc/kernel/syscalls.c - 1.3 arch/ppc/kernel/time.c - 1.2 arch/ppc/platforms/pmac_pic.c - 1.3 arch/ppc/syslib/open_pic.c - 1.3 arch/ppc64/Kconfig - 1.5 arch/ppc64/Makefile - 1.3 arch/ppc64/boot/Makefile - 1.2 arch/ppc64/defconfig - 1.3 arch/ppc64/kernel/Makefile - 1.5 arch/ppc64/kernel/binfmt_elf32.c - 1.2 arch/ppc64/kernel/chrp_setup.c - 1.4 arch/ppc64/kernel/cputable.c - 1.4 arch/ppc64/kernel/eeh.c - 1.3 arch/ppc64/kernel/entry.S - 1.3 arch/ppc64/kernel/head.S - 1.6 arch/ppc64/kernel/iSeries_irq.c - 1.3 arch/ppc64/kernel/iSeries_pci.c - 1.4 arch/ppc64/kernel/iSeries_setup.c - 1.4 arch/ppc64/kernel/ioctl32.c - 1.2 arch/ppc64/kernel/irq.c - 1.4 arch/ppc64/kernel/lmb.c - 1.2 arch/ppc64/kernel/mf.c - 1.3 arch/ppc64/kernel/misc.S - 1.4 arch/ppc64/kernel/open_pic.c - 1.4 arch/ppc64/kernel/pSeries_htab.c - 1.3 arch/ppc64/kernel/pSeries_lpar.c - 1.5 arch/ppc64/kernel/pSeries_pci.c - 1.5 arch/ppc64/kernel/pci.c - 1.4 arch/ppc64/kernel/pci_dma.c - 1.4 arch/ppc64/kernel/pci_dn.c - 1.4 arch/ppc64/kernel/ppc_ksyms.c - 1.5 arch/ppc64/kernel/process.c - 1.5 arch/ppc64/kernel/prom.c - 1.6 arch/ppc64/kernel/ras.c - 1.3 arch/ppc64/kernel/rtas-proc.c - 1.5 arch/ppc64/kernel/rtas.c - 1.3 arch/ppc64/kernel/rtas_flash.c - 1.4 arch/ppc64/kernel/rtasd.c - 1.4 arch/ppc64/kernel/scanlog.c - 1.4 arch/ppc64/kernel/setup.c - 1.6 arch/ppc64/kernel/signal32.c - 1.4 arch/ppc64/kernel/smp.c - 1.5 arch/ppc64/kernel/stab.c - 1.4 arch/ppc64/kernel/sys_ppc32.c - 1.5 arch/ppc64/kernel/syscalls.c - 1.3 arch/ppc64/kernel/time.c - 1.4 arch/ppc64/kernel/traps.c - 1.4 arch/ppc64/kernel/xics.c - 1.4 arch/ppc64/mm/Makefile - 1.3 arch/ppc64/mm/hugetlbpage.c - 1.5 arch/ppc64/mm/imalloc.c - 1.3 arch/ppc64/mm/init.c - 1.4 arch/ppc64/mm/numa.c - 1.4 arch/ppc64/xmon/xmon.c - 1.5 arch/s390/Kconfig - 1.3 arch/s390/Makefile - 1.3 arch/s390/defconfig - 1.4 arch/s390/kernel/binfmt_elf32.c - 1.2 arch/s390/kernel/compat_ioctl.c - 1.3 arch/s390/kernel/compat_linux.c - 1.4 arch/s390/kernel/compat_linux.h - 1.3 arch/s390/kernel/compat_ptrace.h - 1.2 arch/s390/kernel/compat_wrapper.S - 1.4 arch/s390/kernel/process.c - 1.2 arch/s390/kernel/s390_ext.c - 1.2 arch/s390/kernel/s390_ksyms.c - 1.3 arch/s390/kernel/semaphore.c - 1.3 arch/s390/kernel/smp.c - 1.2 arch/s390/kernel/sys_s390.c - 1.3 arch/s390/kernel/time.c - 1.2 arch/s390/kernel/traps.c - 1.3 arch/s390/lib/Makefile - 1.2 arch/s390/lib/strncpy.S - 1.2 arch/s390/lib/strncpy64.S - 1.2 arch/s390/math-emu/math.c - 1.2 arch/s390/mm/Makefile - 1.3 arch/s390/mm/init.c - 1.3 arch/sh/Kconfig - 1.5 arch/sh/boards/adx/Makefile - 1.3 arch/sh/boards/bigsur/Makefile - 1.3 arch/sh/boards/cat68701/Makefile - 1.3 arch/sh/boards/cqreek/Makefile - 1.3 arch/sh/boards/dmida/Makefile - 1.2 arch/sh/boards/dreamcast/Makefile - 1.3 arch/sh/boards/ec3104/Makefile - 1.3 arch/sh/boards/harp/Makefile - 1.2 arch/sh/boards/hp6xx/hp620/Makefile - 1.2 arch/sh/boards/hp6xx/hp680/Makefile - 1.3 arch/sh/boards/hp6xx/hp690/Makefile - 1.2 arch/sh/boards/mpc1211/Makefile - 1.3 arch/sh/boards/overdrive/Makefile - 1.2 arch/sh/boards/saturn/Makefile - 1.3 arch/sh/boards/se/770x/Makefile - 1.2 arch/sh/boards/se/7751/Makefile - 1.2 arch/sh/boards/sh2000/Makefile - 1.3 arch/sh/boards/unknown/Makefile - 1.2 arch/sh/cchips/hd6446x/hd64461/Makefile - 1.2 arch/sh/cchips/hd6446x/hd64465/Makefile - 1.2 arch/sh/kernel/sys_sh.c - 1.3 arch/sparc/Kconfig - 1.5 arch/sparc/Makefile - 1.3 arch/sparc/kernel/entry.S - 1.3 arch/sparc/kernel/etrap.S - 1.3 arch/sparc/kernel/head.S - 1.2 arch/sparc/kernel/irq.c - 1.5 arch/sparc/kernel/pcic.c - 1.2 arch/sparc/kernel/process.c - 1.4 arch/sparc/kernel/rtrap.S - 1.3 arch/sparc/kernel/sclow.S - 1.2 arch/sparc/kernel/setup.c - 1.3 arch/sparc/kernel/signal.c - 1.3 arch/sparc/kernel/smp.c - 1.3 arch/sparc/kernel/sparc_ksyms.c - 1.4 arch/sparc/kernel/sun4c_irq.c - 1.2 arch/sparc/kernel/sun4d_irq.c - 1.3 arch/sparc/kernel/sun4m_irq.c - 1.2 arch/sparc/kernel/sunos_asm.S - 1.2 arch/sparc/kernel/sunos_ioctl.c - 1.2 arch/sparc/kernel/sys_sparc.c - 1.2 arch/sparc/kernel/sys_sunos.c - 1.2 arch/sparc/kernel/time.c - 1.2 arch/sparc/kernel/trampoline.S - 1.2 arch/sparc/kernel/traps.c - 1.4 arch/sparc/kernel/unaligned.c - 1.2 arch/sparc/kernel/wof.S - 1.3 arch/sparc/kernel/wuf.S - 1.3 arch/sparc/lib/Makefile - 1.2 arch/sparc/lib/ashldi3.S - 1.2 arch/sparc/lib/ashrdi3.S - 1.2 arch/sparc/lib/atomic.S - 1.3 arch/sparc/lib/bitops.S - 1.2 arch/sparc/lib/blockops.S - 1.2 arch/sparc/lib/checksum.S - 1.2 arch/sparc/lib/copy_user.S - 1.2 arch/sparc/lib/locks.S - 1.2 arch/sparc/lib/lshrdi3.S - 1.2 arch/sparc/lib/memcmp.S - 1.2 arch/sparc/lib/memcpy.S - 1.2 arch/sparc/lib/memscan.S - 1.2 arch/sparc/lib/memset.S - 1.2 arch/sparc/lib/strlen.S - 1.2 arch/sparc/lib/strlen_user.S - 1.2 arch/sparc/lib/strncmp.S - 1.2 arch/sparc/lib/strncpy_from_user.S - 1.2 arch/sparc/math-emu/Makefile - 1.2 arch/sparc/mm/fault.c - 1.5 arch/sparc/mm/nosun4c.c - 1.2 arch/sparc/mm/srmmu.c - 1.5 arch/sparc/mm/sun4c.c - 1.3 arch/sparc/mm/viking.S - 1.2 arch/sparc/prom/printf.c - 1.2 arch/sparc64/Kconfig - 1.5 arch/sparc64/defconfig - 1.5 arch/sparc64/kernel/binfmt_elf32.c - 1.2 arch/sparc64/kernel/ioctl32.c - 1.2 arch/sparc64/kernel/irq.c - 1.3 arch/sparc64/kernel/setup.c - 1.4 arch/sparc64/kernel/signal.c - 1.2 arch/sparc64/kernel/smp.c - 1.3 arch/sparc64/kernel/sparc64_ksyms.c - 1.3 arch/sparc64/kernel/sunos_ioctl32.c - 1.2 arch/sparc64/kernel/sys_sparc.c - 1.2 arch/sparc64/kernel/sys_sparc32.c - 1.4 arch/sparc64/kernel/sys_sunos32.c - 1.2 arch/sparc64/kernel/time.c - 1.2 arch/sparc64/lib/debuglocks.c - 1.2 arch/sparc64/mm/init.c - 1.4 arch/sparc64/prom/printf.c - 1.2 arch/sparc64/solaris/ioctl.c - 1.2 arch/sparc64/solaris/socksys.c - 1.2 arch/sparc64/solaris/timod.c - 1.2 arch/um/drivers/net_kern.c - 1.2 arch/um/include/kern_util.h - 1.2 arch/um/kernel/irq.c - 1.3 arch/um/kernel/sys_call_table.c - 1.2 arch/um/kernel/syscall_kern.c - 1.2 arch/um/kernel/time.c - 1.2 arch/v850/Kconfig - 1.2 arch/v850/kernel/ptrace.c - 1.2 arch/v850/kernel/syscalls.c - 1.2 arch/v850/kernel/time.c - 1.2 arch/x86_64/Kconfig - 1.4 arch/x86_64/Makefile - 1.3 arch/x86_64/boot/setup.S - 1.2 arch/x86_64/defconfig - 1.5 arch/x86_64/ia32/Makefile - 1.3 arch/x86_64/ia32/ia32_binfmt.c - 1.3 arch/x86_64/ia32/ia32_ioctl.c - 1.3 arch/x86_64/ia32/ipc32.c - 1.2 arch/x86_64/ia32/ptrace32.c - 1.3 arch/x86_64/ia32/sys_ia32.c - 1.5 arch/x86_64/kernel/Makefile - 1.3 arch/x86_64/kernel/acpi/boot.c - 1.5 arch/x86_64/kernel/aperture.c - 1.3 arch/x86_64/kernel/apic.c - 1.3 arch/x86_64/kernel/bluesmoke.c - 1.3 arch/x86_64/kernel/cpufreq/Kconfig - 1.2 arch/x86_64/kernel/early_printk.c - 1.2 arch/x86_64/kernel/head.S - 1.3 arch/x86_64/kernel/head64.c - 1.2 arch/x86_64/kernel/i8259.c - 1.3 arch/x86_64/kernel/io_apic.c - 1.4 arch/x86_64/kernel/irq.c - 1.3 arch/x86_64/kernel/mpparse.c - 1.5 arch/x86_64/kernel/nmi.c - 1.3 arch/x86_64/kernel/pci-gart.c - 1.6 arch/x86_64/kernel/process.c - 1.4 arch/x86_64/kernel/setup.c - 1.4 arch/x86_64/kernel/setup64.c - 1.2 arch/x86_64/kernel/smpboot.c - 1.2 arch/x86_64/kernel/sys_x86_64.c - 1.5 arch/x86_64/kernel/syscall.c - 1.2 arch/x86_64/kernel/time.c - 1.4 arch/x86_64/kernel/traps.c - 1.4 arch/x86_64/kernel/x8664_ksyms.c - 1.3 arch/x86_64/lib/copy_page.S - 1.2 arch/x86_64/lib/csum-copy.S - 1.2 arch/x86_64/lib/csum-partial.c - 1.3 arch/x86_64/mm/init.c - 1.3 arch/x86_64/mm/k8topology.c - 1.4 arch/x86_64/oprofile/Makefile - 1.2 crypto/Kconfig - 1.2 crypto/Makefile - 1.2 crypto/cipher.c - 1.2 crypto/internal.h - 1.2 crypto/tcrypt.c - 1.3 crypto/tcrypt.h - 1.3 drivers/Kconfig - 1.4 drivers/Makefile - 1.2 drivers/acorn/char/i2c.c - 1.4 drivers/acorn/char/pcf8583.c - 1.2 drivers/acpi/Kconfig - 1.4 drivers/acpi/dispatcher/dsmthdat.c - 1.4 drivers/acpi/dispatcher/dsobject.c - 1.3 drivers/acpi/dispatcher/dsopcode.c - 1.3 drivers/acpi/dispatcher/dsutils.c - 1.3 drivers/acpi/dispatcher/dswstate.c - 1.3 drivers/acpi/executer/exconvrt.c - 1.3 drivers/acpi/executer/exfldio.c - 1.3 drivers/acpi/executer/exmisc.c - 1.3 drivers/acpi/executer/exoparg2.c - 1.3 drivers/acpi/executer/exprep.c - 1.3 drivers/acpi/executer/exresolv.c - 1.3 drivers/acpi/executer/exresop.c - 1.3 drivers/acpi/executer/exstore.c - 1.3 drivers/acpi/executer/exstoren.c - 1.3 drivers/acpi/hardware/hwgpe.c - 1.3 drivers/acpi/hardware/hwregs.c - 1.3 drivers/acpi/hardware/hwsleep.c - 1.3 drivers/acpi/namespace/nsaccess.c - 1.3 drivers/acpi/namespace/nseval.c - 1.3 drivers/acpi/namespace/nsutils.c - 1.3 drivers/acpi/namespace/nsxfname.c - 1.3 drivers/acpi/parser/psargs.c - 1.3 drivers/acpi/pci_link.c - 1.4 drivers/acpi/resources/rsxface.c - 1.3 drivers/acpi/sleep/proc.c - 1.3 drivers/acpi/tables.c - 1.4 drivers/acpi/utilities/uteval.c - 1.3 drivers/acpi/utilities/utglobal.c - 1.3 drivers/acpi/utils.c - 1.2 drivers/atm/horizon.c - 1.3 drivers/base/Kconfig - 1.2 drivers/base/bus.c - 1.3 drivers/base/class.c - 1.4 drivers/base/core.c - 1.4 drivers/base/cpu.c - 1.2 drivers/base/driver.c - 1.2 drivers/base/firmware_class.c - 1.4 drivers/base/init.c - 1.2 drivers/base/node.c - 1.3 drivers/base/power/main.c - 1.2 drivers/base/power/runtime.c - 1.2 drivers/base/power/shutdown.c - 1.2 drivers/base/sys.c - 1.2 drivers/block/Kconfig - 1.3 drivers/block/Makefile - 1.2 drivers/block/cryptoloop.c - 1.2 drivers/block/floppy.c - 1.5 drivers/block/genhd.c - 1.4 drivers/block/ioctl.c - 1.2 drivers/block/ll_rw_blk.c - 1.5 drivers/block/loop.c - 1.3 drivers/block/nbd.c - 1.2 drivers/block/rd.c - 1.2 drivers/block/swim3.c - 1.3 drivers/bluetooth/Kconfig - 1.3 drivers/bluetooth/bluecard_cs.c - 1.3 drivers/bluetooth/bt3c_cs.c - 1.3 drivers/bluetooth/btuart_cs.c - 1.3 drivers/bluetooth/dtl1_cs.c - 1.3 drivers/bluetooth/hci_bcsp.c - 1.2 drivers/bluetooth/hci_h4.c - 1.2 drivers/bluetooth/hci_ldisc.c - 1.2 drivers/bluetooth/hci_uart.h - 1.2 drivers/bluetooth/hci_usb.c - 1.3 drivers/bluetooth/hci_usb.h - 1.3 drivers/bluetooth/hci_vhci.c - 1.2 drivers/bluetooth/hci_vhci.h - 1.2 drivers/cdrom/Makefile - 1.2 drivers/char/Kconfig - 1.4 drivers/char/agp/Kconfig - 1.3 drivers/char/agp/Makefile - 1.2 drivers/char/agp/amd64-agp.c - 1.3 drivers/char/agp/intel-agp.c - 1.3 drivers/char/amiserial.c - 1.2 drivers/char/cyclades.c - 1.2 drivers/char/drm/r128_state.c - 1.2 drivers/char/epca.c - 1.2 drivers/char/esp.c - 1.2 drivers/char/ftape/compressor/zftape-compress.c - 1.2 drivers/char/genrtc.c - 1.3 drivers/char/h8.c - 1.2 drivers/char/hw_random.c - 1.2 drivers/char/ip2/ip2.h - 1.2 drivers/char/ip2main.c - 1.2 drivers/char/ipmi/ipmi_kcs_intf.c - 1.2 drivers/char/ipmi/ipmi_kcs_sm.c - 1.2 drivers/char/isicom.c - 1.2 drivers/char/istallion.c - 1.3 drivers/char/lp.c - 1.3 drivers/char/mem.c - 1.3 drivers/char/misc.c - 1.3 drivers/char/moxa.c - 1.3 drivers/char/mxser.c - 1.3 drivers/char/n_tty.c - 1.2 drivers/char/pcxx.c - 1.2 drivers/char/pty.c - 1.2 drivers/char/raw.c - 1.3 drivers/char/rio/rio_linux.c - 1.2 drivers/char/rio/rioctrl.c - 1.2 drivers/char/riscom8.c - 1.2 drivers/char/rocket.c - 1.2 drivers/char/rocket_int.h - 1.2 drivers/char/serial167.c - 1.2 drivers/char/sh-sci.c - 1.4 drivers/char/sn_serial.c - 1.10 drivers/char/specialix.c - 1.3 drivers/char/stallion.c - 1.2 drivers/char/sx.c - 1.3 drivers/char/tipar.c - 1.2 drivers/char/tty_io.c - 1.5 drivers/char/vt.c - 1.4 drivers/char/vt_ioctl.c - 1.4 drivers/char/watchdog/Kconfig - 1.4 drivers/char/watchdog/Makefile - 1.4 drivers/char/watchdog/cpu5wdt.c - 1.3 drivers/char/watchdog/eurotechwdt.c - 1.3 drivers/char/watchdog/ib700wdt.c - 1.4 drivers/char/watchdog/machzwd.c - 1.4 drivers/char/watchdog/mixcomwd.c - 1.4 drivers/char/watchdog/pcwd.c - 1.4 drivers/char/watchdog/sa1100_wdt.c - 1.4 drivers/char/watchdog/sc1200wdt.c - 1.3 drivers/char/watchdog/w83877f_wdt.c - 1.3 drivers/char/watchdog/wdt285.c - 1.3 drivers/char/watchdog/wdt977.c - 1.3 drivers/char/watchdog/wdt_pci.c - 1.3 drivers/cpufreq/Kconfig - 1.3 drivers/cpufreq/cpufreq.c - 1.3 drivers/cpufreq/proc_intf.c - 1.2 drivers/i2c/busses/i2c-elv.c - 1.3 drivers/i2c/busses/i2c-savage4.c - 1.4 drivers/i2c/busses/i2c-velleman.c - 1.4 drivers/i2c/busses/i2c-voodoo3.c - 1.3 drivers/i2c/chips/lm85.c - 1.5 drivers/ide/Kconfig - 1.6 drivers/ide/arm/icside.c - 1.5 drivers/ide/ide-cd.c - 1.7 drivers/ide/ide-default.c - 1.2 drivers/ide/ide-disk.c - 1.4 drivers/ide/ide-floppy.c - 1.4 drivers/ide/ide-io.c - 1.3 drivers/ide/ide-probe.c - 1.3 drivers/ide/ide-proc.c - 1.3 drivers/ide/ide-tape.c - 1.4 drivers/ide/ide-taskfile.c - 1.4 drivers/ide/ide.c - 1.9 drivers/ide/pci/Makefile - 1.4 drivers/ide/pci/aec62xx.c - 1.4 drivers/ide/pci/aec62xx.h - 1.3 drivers/ide/pci/alim15x3.c - 1.4 drivers/ide/pci/alim15x3.h - 1.3 drivers/ide/pci/amd74xx.c - 1.4 drivers/ide/pci/amd74xx.h - 1.3 drivers/ide/pci/cmd64x.c - 1.4 drivers/ide/pci/cmd64x.h - 1.3 drivers/ide/pci/cs5520.c - 1.3 drivers/ide/pci/cs5520.h - 1.3 drivers/ide/pci/cs5530.c - 1.4 drivers/ide/pci/cs5530.h - 1.3 drivers/ide/pci/generic.c - 1.3 drivers/ide/pci/hpt34x.c - 1.4 drivers/ide/pci/hpt34x.h - 1.3 drivers/ide/pci/hpt366.c - 1.4 drivers/ide/pci/hpt366.h - 1.3 drivers/ide/pci/it8172.c - 1.4 drivers/ide/pci/ns87415.c - 1.3 drivers/ide/pci/opti621.c - 1.3 drivers/ide/pci/pdc202xx_new.c - 1.5 drivers/ide/pci/pdc202xx_new.h - 1.3 drivers/ide/pci/pdc202xx_old.c - 1.5 drivers/ide/pci/pdc202xx_old.h - 1.3 drivers/ide/pci/piix.c - 1.5 drivers/ide/pci/piix.h - 1.3 drivers/ide/pci/rz1000.c - 1.3 drivers/ide/pci/sc1200.c - 1.5 drivers/ide/pci/sc1200.h - 1.3 drivers/ide/pci/serverworks.c - 1.4 drivers/ide/pci/serverworks.h - 1.3 drivers/ide/pci/siimage.c - 1.5 drivers/ide/pci/siimage.h - 1.3 drivers/ide/pci/sis5513.c - 1.4 drivers/ide/pci/sis5513.h - 1.3 drivers/ide/pci/sl82c105.c - 1.4 drivers/ide/pci/slc90e66.c - 1.4 drivers/ide/pci/slc90e66.h - 1.3 drivers/ide/pci/triflex.c - 1.5 drivers/ide/pci/triflex.h - 1.4 drivers/ide/pci/trm290.c - 1.4 drivers/ide/pci/via82cxxx.c - 1.3 drivers/ide/pci/via82cxxx.h - 1.3 drivers/ide/ppc/pmac.c - 1.5 drivers/ide/setup-pci.c - 1.5 drivers/ieee1394/Kconfig - 1.4 drivers/ieee1394/Makefile - 1.2 drivers/ieee1394/amdtp.c - 1.4 drivers/ieee1394/csr.c - 1.3 drivers/ieee1394/csr.h - 1.2 drivers/ieee1394/dma.c - 1.3 drivers/ieee1394/dma.h - 1.2 drivers/ieee1394/dv1394.c - 1.4 drivers/ieee1394/eth1394.c - 1.5 drivers/ieee1394/eth1394.h - 1.2 drivers/ieee1394/highlevel.c - 1.6 drivers/ieee1394/highlevel.h - 1.4 drivers/ieee1394/hosts.c - 1.4 drivers/ieee1394/hosts.h - 1.4 drivers/ieee1394/ieee1394.h - 1.2 drivers/ieee1394/ieee1394_core.c - 1.4 drivers/ieee1394/ieee1394_core.h - 1.4 drivers/ieee1394/ieee1394_transactions.c - 1.3 drivers/ieee1394/iso.c - 1.3 drivers/ieee1394/nodemgr.c - 1.3 drivers/ieee1394/nodemgr.h - 1.3 drivers/ieee1394/ohci1394.c - 1.4 drivers/ieee1394/ohci1394.h - 1.2 drivers/ieee1394/pcilynx.c - 1.3 drivers/ieee1394/pcilynx.h - 1.2 drivers/ieee1394/raw1394-private.h - 1.2 drivers/ieee1394/raw1394.c - 1.5 drivers/ieee1394/raw1394.h - 1.3 drivers/ieee1394/sbp2.c - 1.5 drivers/ieee1394/sbp2.h - 1.3 drivers/ieee1394/video1394.c - 1.5 drivers/input/serio/ambakmi.c - 1.2 drivers/input/serio/i8042.c - 1.5 drivers/isdn/Kconfig - 1.3 drivers/isdn/Makefile - 1.3 drivers/isdn/act2000/Kconfig - 1.2 drivers/isdn/act2000/act2000.h - 1.2 drivers/isdn/act2000/act2000_isa.c - 1.2 drivers/isdn/act2000/capi.c - 1.2 drivers/isdn/act2000/capi.h - 1.2 drivers/isdn/act2000/module.c - 1.2 drivers/isdn/capi/Kconfig - 1.2 drivers/isdn/capi/capi.c - 1.2 drivers/isdn/capi/capidrv.c - 1.2 drivers/isdn/capi/capifs.c - 1.2 drivers/isdn/capi/capifs.h - 1.2 drivers/isdn/capi/kcapi.c - 1.2 drivers/isdn/capi/kcapi.h - 1.2 drivers/isdn/capi/kcapi_proc.c - 1.2 drivers/isdn/hardware/Kconfig - 1.3 drivers/isdn/hardware/avm/Kconfig - 1.2 drivers/isdn/hardware/avm/b1.c - 1.2 drivers/isdn/hardware/avm/b1dma.c - 1.2 drivers/isdn/hardware/avm/b1isa.c - 1.2 drivers/isdn/hardware/avm/b1pci.c - 1.2 drivers/isdn/hardware/avm/b1pcmcia.c - 1.2 drivers/isdn/hardware/avm/c4.c - 1.2 drivers/isdn/hardware/avm/t1isa.c - 1.2 drivers/isdn/hardware/avm/t1pci.c - 1.2 drivers/isdn/hardware/eicon/Kconfig - 1.2 drivers/isdn/hardware/eicon/divasmain.c - 1.3 drivers/isdn/hisax/Kconfig - 1.2 drivers/isdn/hisax/Makefile - 1.2 drivers/isdn/hisax/amd7930_fn.c - 1.2 drivers/isdn/hisax/amd7930_fn.h - 1.2 drivers/isdn/hisax/arcofi.c - 1.2 drivers/isdn/hisax/asuscom.c - 1.2 drivers/isdn/hisax/avm_a1.c - 1.2 drivers/isdn/hisax/avm_a1p.c - 1.2 drivers/isdn/hisax/avm_pci.c - 1.2 drivers/isdn/hisax/avma1_cs.c - 1.3 drivers/isdn/hisax/bkm_a4t.c - 1.2 drivers/isdn/hisax/bkm_a8.c - 1.2 drivers/isdn/hisax/callc.c - 1.2 drivers/isdn/hisax/cert.c - 1.2 drivers/isdn/hisax/config.c - 1.2 drivers/isdn/hisax/diva.c - 1.2 drivers/isdn/hisax/elsa.c - 1.2 drivers/isdn/hisax/elsa_cs.c - 1.3 drivers/isdn/hisax/elsa_ser.c - 1.2 drivers/isdn/hisax/enternow.h - 1.2 drivers/isdn/hisax/enternow_pci.c - 1.2 drivers/isdn/hisax/gazel.c - 1.2 drivers/isdn/hisax/hfc_2bds0.c - 1.2 drivers/isdn/hisax/hfc_2bds0.h - 1.2 drivers/isdn/hisax/hfc_2bs0.c - 1.2 drivers/isdn/hisax/hfc_2bs0.h - 1.2 drivers/isdn/hisax/hfc_pci.c - 1.2 drivers/isdn/hisax/hfc_pci.h - 1.2 drivers/isdn/hisax/hfc_sx.c - 1.2 drivers/isdn/hisax/hfcscard.c - 1.2 drivers/isdn/hisax/hisax.h - 1.2 drivers/isdn/hisax/hisax_debug.h - 1.2 drivers/isdn/hisax/hisax_fcclassic.c - 1.2 drivers/isdn/hisax/hisax_fcclassic.h - 1.2 drivers/isdn/hisax/hisax_fcpcipnp.c - 1.2 drivers/isdn/hisax/hisax_fcpcipnp.h - 1.2 drivers/isdn/hisax/hisax_hfcpci.c - 1.3 drivers/isdn/hisax/hisax_hfcpci.h - 1.2 drivers/isdn/hisax/hisax_hscx.c - 1.2 drivers/isdn/hisax/hisax_hscx.h - 1.2 drivers/isdn/hisax/hisax_isac.c - 1.2 drivers/isdn/hisax/hisax_isac.h - 1.2 drivers/isdn/hisax/hscx.c - 1.2 drivers/isdn/hisax/hscx.h - 1.2 drivers/isdn/hisax/hscx_irq.c - 1.2 drivers/isdn/hisax/icc.c - 1.2 drivers/isdn/hisax/icc.h - 1.2 drivers/isdn/hisax/ipac.c - 1.2 drivers/isdn/hisax/ipac.h - 1.2 drivers/isdn/hisax/ipacx.c - 1.2 drivers/isdn/hisax/ipacx.h - 1.2 drivers/isdn/hisax/isac.c - 1.2 drivers/isdn/hisax/isac.h - 1.2 drivers/isdn/hisax/isar.c - 1.2 drivers/isdn/hisax/isar.h - 1.2 drivers/isdn/hisax/isdnl1.c - 1.2 drivers/isdn/hisax/isdnl1.h - 1.2 drivers/isdn/hisax/isdnl2.c - 1.2 drivers/isdn/hisax/isdnl3.c - 1.2 drivers/isdn/hisax/isurf.c - 1.2 drivers/isdn/hisax/ix1_micro.c - 1.2 drivers/isdn/hisax/jade.c - 1.2 drivers/isdn/hisax/jade.h - 1.2 drivers/isdn/hisax/jade_irq.c - 1.2 drivers/isdn/hisax/l3_1tr6.c - 1.2 drivers/isdn/hisax/l3dss1.c - 1.2 drivers/isdn/hisax/l3ni1.c - 1.2 drivers/isdn/hisax/md5sums.asc - 1.2 drivers/isdn/hisax/mic.c - 1.2 drivers/isdn/hisax/netjet.c - 1.2 drivers/isdn/hisax/netjet.h - 1.2 drivers/isdn/hisax/niccy.c - 1.2 drivers/isdn/hisax/nj_s.c - 1.2 drivers/isdn/hisax/nj_u.c - 1.2 drivers/isdn/hisax/q931.c - 1.2 drivers/isdn/hisax/rawhdlc.c - 1.2 drivers/isdn/hisax/rawhdlc.h - 1.2 drivers/isdn/hisax/s0box.c - 1.2 drivers/isdn/hisax/saphir.c - 1.2 drivers/isdn/hisax/sedlbauer.c - 1.2 drivers/isdn/hisax/sedlbauer_cs.c - 1.3 drivers/isdn/hisax/sportster.c - 1.2 drivers/isdn/hisax/st5481.h - 1.2 drivers/isdn/hisax/st5481_b.c - 1.2 drivers/isdn/hisax/st5481_d.c - 1.2 drivers/isdn/hisax/st5481_init.c - 1.2 drivers/isdn/hisax/st5481_usb.c - 1.2 drivers/isdn/hisax/tei.c - 1.2 drivers/isdn/hisax/teleint.c - 1.2 drivers/isdn/hisax/teles0.c - 1.2 drivers/isdn/hisax/teles3.c - 1.2 drivers/isdn/hisax/telespci.c - 1.2 drivers/isdn/hisax/w6692.c - 1.2 drivers/isdn/hisax/w6692.h - 1.2 drivers/isdn/hysdn/Kconfig - 1.2 drivers/isdn/hysdn/hysdn_defs.h - 1.2 drivers/isdn/hysdn/hysdn_proclog.c - 1.2 drivers/isdn/i4l/Kconfig - 1.2 drivers/isdn/i4l/Makefile - 1.2 drivers/isdn/i4l/isdn_audio.c - 1.2 drivers/isdn/i4l/isdn_audio.h - 1.2 drivers/isdn/i4l/isdn_ciscohdlck.c - 1.2 drivers/isdn/i4l/isdn_ciscohdlck.h - 1.2 drivers/isdn/i4l/isdn_common.c - 1.2 drivers/isdn/i4l/isdn_common.h - 1.2 drivers/isdn/i4l/isdn_concap.c - 1.2 drivers/isdn/i4l/isdn_concap.h - 1.2 drivers/isdn/i4l/isdn_fsm.c - 1.2 drivers/isdn/i4l/isdn_net.c - 1.2 drivers/isdn/i4l/isdn_net.h - 1.2 drivers/isdn/i4l/isdn_net_lib.c - 1.2 drivers/isdn/i4l/isdn_net_lib.h - 1.2 drivers/isdn/i4l/isdn_ppp.c - 1.2 drivers/isdn/i4l/isdn_ppp.h - 1.2 drivers/isdn/i4l/isdn_ppp_ccp.c - 1.3 drivers/isdn/i4l/isdn_ppp_ccp.h - 1.2 drivers/isdn/i4l/isdn_ppp_mp.c - 1.2 drivers/isdn/i4l/isdn_ppp_mp.h - 1.2 drivers/isdn/i4l/isdn_ppp_vj.c - 1.2 drivers/isdn/i4l/isdn_ppp_vj.h - 1.2 drivers/isdn/i4l/isdn_tty.c - 1.2 drivers/isdn/i4l/isdn_tty.h - 1.2 drivers/isdn/i4l/isdn_ttyfax.c - 1.2 drivers/isdn/i4l/isdn_ttyfax.h - 1.2 drivers/isdn/i4l/isdn_v110.c - 1.2 drivers/isdn/i4l/isdn_v110.h - 1.2 drivers/isdn/i4l/isdn_x25iface.c - 1.2 drivers/isdn/i4l/isdn_x25iface.h - 1.2 drivers/isdn/icn/Kconfig - 1.2 drivers/isdn/icn/icn.c - 1.2 drivers/isdn/isdnloop/isdnloop.c - 1.2 drivers/isdn/pcbit/Kconfig - 1.2 drivers/isdn/pcbit/drv.c - 1.2 drivers/isdn/pcbit/edss1.c - 1.2 drivers/isdn/pcbit/layer2.c - 1.2 drivers/isdn/pcbit/pcbit.h - 1.2 drivers/isdn/sc/Kconfig - 1.2 drivers/isdn/sc/command.c - 1.2 drivers/isdn/sc/event.c - 1.2 drivers/isdn/sc/hardware.h - 1.2 drivers/isdn/sc/init.c - 1.2 drivers/isdn/sc/interrupt.c - 1.2 drivers/isdn/sc/ioctl.c - 1.2 drivers/isdn/sc/message.c - 1.2 drivers/isdn/sc/packet.c - 1.2 drivers/isdn/sc/shmem.c - 1.2 drivers/isdn/sc/timer.c - 1.2 drivers/isdn/tpam/Kconfig - 1.2 drivers/macintosh/apm_emu.c - 1.2 drivers/macintosh/macio_asic.c - 1.4 drivers/macintosh/macserial.c - 1.2 drivers/macintosh/via-pmu.c - 1.5 drivers/md/Kconfig - 1.4 drivers/md/Makefile - 1.4 drivers/md/dm-ioctl-v1.c - 1.3 drivers/md/dm-ioctl-v4.c - 1.3 drivers/md/dm-ioctl.c - 1.2 drivers/md/dm-stripe.c - 1.2 drivers/md/dm-table.c - 1.3 drivers/md/dm.c - 1.4 drivers/md/dm.h - 1.3 drivers/md/md.c - 1.4 drivers/md/raid1.c - 1.4 drivers/md/raid5.c - 1.5 drivers/media/common/saa7146_core.c - 1.4 drivers/media/common/saa7146_video.c - 1.5 drivers/media/dvb/Kconfig - 1.3 drivers/media/dvb/b2c2/skystar2.c - 1.3 drivers/media/dvb/dvb-core/dvb_frontend.c - 1.4 drivers/media/dvb/dvb-core/dvb_net.c - 1.2 drivers/media/dvb/dvb-core/dvb_ringbuffer.c - 1.3 drivers/media/dvb/frontends/Kconfig - 1.3 drivers/media/dvb/frontends/Makefile - 1.3 drivers/media/dvb/frontends/alps_tdlb7.c - 1.2 drivers/media/dvb/frontends/alps_tdmb7.c - 1.4 drivers/media/dvb/frontends/nxt6000.c - 1.4 drivers/media/dvb/frontends/sp887x.c - 1.3 drivers/media/dvb/frontends/stv0299.c - 1.3 drivers/media/dvb/frontends/tda1004x.c - 1.3 drivers/media/dvb/frontends/ves1820.c - 1.4 drivers/media/dvb/ttpci/av7110.c - 1.4 drivers/media/dvb/ttpci/budget-av.c - 1.2 drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c - 1.3 drivers/media/dvb/ttusb-budget/dvb-ttusb-dspbootcode.h - 1.2 drivers/media/dvb/ttusb-dec/ttusb_dec.c - 1.6 drivers/media/radio/Kconfig - 1.2 drivers/media/radio/Makefile - 1.2 drivers/media/video/Kconfig - 1.4 drivers/media/video/Makefile - 1.3 drivers/media/video/c-qcam.c - 1.2 drivers/media/video/cpia_pp.c - 1.2 drivers/media/video/saa5249.c - 1.2 drivers/media/video/tuner.c - 1.5 drivers/media/video/v4l1-compat.c - 1.3 drivers/media/video/videocodec.c - 1.2 drivers/media/video/videocodec.h - 1.2 drivers/media/video/w9966.c - 1.3 drivers/media/video/zr36016.c - 1.2 drivers/media/video/zr36050.c - 1.2 drivers/media/video/zr36050.h - 1.2 drivers/media/video/zr36060.c - 1.2 drivers/message/fusion/Kconfig - 1.2 drivers/message/fusion/mptbase.c - 1.4 drivers/message/fusion/mptbase.h - 1.5 drivers/message/fusion/mptlan.c - 1.3 drivers/message/fusion/mptscsih.c - 1.5 drivers/message/i2o/Kconfig - 1.3 drivers/message/i2o/i2o_block.c - 1.2 drivers/message/i2o/i2o_core.c - 1.2 drivers/message/i2o/i2o_scsi.c - 1.2 drivers/misc/Kconfig - 1.2 drivers/misc/Makefile - 1.2 drivers/mtd/afs.c - 1.2 drivers/mtd/chips/cfi_cmdset_0020.c - 1.3 drivers/mtd/devices/blkmtd.c - 1.2 drivers/mtd/maps/integrator-flash.c - 1.2 drivers/mtd/maps/lubbock-flash.c - 1.2 drivers/mtd/maps/map_funcs.c - 1.2 drivers/mtd/maps/solutionengine.c - 1.2 drivers/mtd/mtd_blkdevs.c - 1.2 drivers/net/3c505.c - 1.3 drivers/net/3c509.c - 1.2 drivers/net/3c59x.c - 1.3 drivers/net/8390.c - 1.3 drivers/net/Kconfig - 1.4 drivers/net/Makefile - 1.4 drivers/net/a2065.c - 1.4 drivers/net/acenic.c - 1.3 drivers/net/amd8111e.c - 1.2 drivers/net/apne.c - 1.4 drivers/net/appletalk/cops.c - 1.2 drivers/net/ariadne.c - 1.3 drivers/net/arm/am79c961a.c - 1.3 drivers/net/atari_pamsnet.c - 1.3 drivers/net/bonding/bond_3ad.c - 1.3 drivers/net/bonding/bond_3ad.h - 1.3 drivers/net/bonding/bond_alb.c - 1.3 drivers/net/bonding/bond_alb.h - 1.3 drivers/net/bonding/bond_main.c - 1.4 drivers/net/bonding/bonding.h - 1.3 drivers/net/bsd_comp.c - 1.2 drivers/net/depca.c - 1.3 drivers/net/dgrs.c - 1.2 drivers/net/e100/LICENSE - 1.2 drivers/net/e100/Makefile - 1.2 drivers/net/e100/e100.h - 1.2 drivers/net/e100/e100_config.c - 1.3 drivers/net/e100/e100_config.h - 1.2 drivers/net/e100/e100_eeprom.c - 1.2 drivers/net/e100/e100_main.c - 1.4 drivers/net/e100/e100_phy.c - 1.3 drivers/net/e100/e100_phy.h - 1.2 drivers/net/e100/e100_test.c - 1.2 drivers/net/e100/e100_ucode.h - 1.2 drivers/net/e1000/e1000.h - 1.3 drivers/net/e1000/e1000_hw.h - 1.3 drivers/net/e1000/e1000_main.c - 1.3 drivers/net/e1000/e1000_osdep.h - 1.3 drivers/net/fc/iph5526.c - 1.3 drivers/net/fec.c - 1.2 drivers/net/gt96100eth.c - 1.3 drivers/net/hamradio/6pack.c - 1.3 drivers/net/hamradio/Kconfig - 1.2 drivers/net/hamradio/baycom_epp.c - 1.4 drivers/net/hp100.c - 1.3 drivers/net/hydra.c - 1.4 drivers/net/irda/Kconfig - 1.3 drivers/net/irda/Makefile - 1.3 drivers/net/irda/ali-ircc.c - 1.5 drivers/net/irda/au1k_ir.c - 1.2 drivers/net/irda/donauboe.c - 1.2 drivers/net/irda/irda-usb.c - 1.2 drivers/net/irda/irport.c - 1.3 drivers/net/irda/irtty-sir.c - 1.2 drivers/net/irda/nsc-ircc.c - 1.4 drivers/net/irda/sir_dev.c - 1.3 drivers/net/irda/smsc-ircc2.c - 1.4 drivers/net/irda/via-ircc.c - 1.4 drivers/net/irda/via-ircc.h - 1.2 drivers/net/irda/vlsi_ir.c - 1.2 drivers/net/irda/w83977af_ir.c - 1.4 drivers/net/isa-skeleton.c - 1.2 drivers/net/lasi_82596.c - 1.3 drivers/net/loopback.c - 1.2 drivers/net/meth.c - 1.3 drivers/net/ne.c - 1.4 drivers/net/net_init.c - 1.3 drivers/net/ns83820.c - 1.4 drivers/net/pcmcia/pcnet_cs.c - 1.5 drivers/net/pcnet32.c - 1.3 drivers/net/ppp_deflate.c - 1.3 drivers/net/ppp_generic.c - 1.3 drivers/net/pppoe.c - 1.5 drivers/net/r8169.c - 1.2 drivers/net/saa9730.c - 1.3 drivers/net/sb1250-mac.c - 1.3 drivers/net/shaper.c - 1.3 drivers/net/sis190.c - 1.2 drivers/net/sis900.c - 1.3 drivers/net/sk98lin/h/lm80.h - 1.3 drivers/net/sk98lin/h/skaddr.h - 1.3 drivers/net/sk98lin/h/skcsum.h - 1.4 drivers/net/sk98lin/h/skdebug.h - 1.3 drivers/net/sk98lin/h/skdrv1st.h - 1.4 drivers/net/sk98lin/h/skdrv2nd.h - 1.4 drivers/net/sk98lin/h/skerror.h - 1.3 drivers/net/sk98lin/h/skgedrv.h - 1.3 drivers/net/sk98lin/h/skgehw.h - 1.4 drivers/net/sk98lin/h/skgehwt.h - 1.4 drivers/net/sk98lin/h/skgei2c.h - 1.4 drivers/net/sk98lin/h/skgeinit.h - 1.4 drivers/net/sk98lin/h/skgepnm2.h - 1.3 drivers/net/sk98lin/h/skgepnmi.h - 1.4 drivers/net/sk98lin/h/skgesirq.h - 1.3 drivers/net/sk98lin/h/ski2c.h - 1.4 drivers/net/sk98lin/h/skqueue.h - 1.4 drivers/net/sk98lin/h/skrlmt.h - 1.3 drivers/net/sk98lin/h/sktimer.h - 1.4 drivers/net/sk98lin/h/sktypes.h - 1.4 drivers/net/sk98lin/h/skversion.h - 1.5 drivers/net/sk98lin/h/skvpd.h - 1.3 drivers/net/sk98lin/h/xmac_ii.h - 1.4 drivers/net/sk98lin/skaddr.c - 1.3 drivers/net/sk98lin/skcsum.c - 1.4 drivers/net/sk98lin/skdim.c - 1.4 drivers/net/sk98lin/skge.c - 1.6 drivers/net/sk98lin/skgehwt.c - 1.4 drivers/net/sk98lin/skgeinit.c - 1.4 drivers/net/sk98lin/skgemib.c - 1.4 drivers/net/sk98lin/skgepnmi.c - 1.4 drivers/net/sk98lin/skgesirq.c - 1.4 drivers/net/sk98lin/ski2c.c - 1.4 drivers/net/sk98lin/sklm80.c - 1.4 drivers/net/sk98lin/skproc.c - 1.4 drivers/net/sk98lin/skqueue.c - 1.4 drivers/net/sk98lin/skrlmt.c - 1.3 drivers/net/sk98lin/sktimer.c - 1.4 drivers/net/sk98lin/skvpd.c - 1.3 drivers/net/sk98lin/skxmac2.c - 1.4 drivers/net/skfp/skfddi.c - 1.3 drivers/net/sun3lance.c - 1.4 drivers/net/sundance.c - 1.3 drivers/net/sungem.c - 1.3 drivers/net/tg3.c - 1.5 drivers/net/tg3.h - 1.2 drivers/net/tokenring/3c359.c - 1.4 drivers/net/tokenring/3c359_microcode.h - 1.2 drivers/net/tokenring/abyss.c - 1.3 drivers/net/tokenring/ibmtr.c - 1.3 drivers/net/tokenring/madgemc.c - 1.3 drivers/net/tokenring/proteon.c - 1.3 drivers/net/tokenring/skisa.c - 1.3 drivers/net/tokenring/tms380tr.c - 1.3 drivers/net/tokenring/tms380tr.h - 1.2 drivers/net/tokenring/tms380tr_microcode.h - 1.2 drivers/net/tokenring/tmspci.c - 1.3 drivers/net/tulip/de4x5.c - 1.2 drivers/net/tulip/interrupt.c - 1.3 drivers/net/tulip/xircom_tulip_cb.c - 1.3 drivers/net/tun.c - 1.3 drivers/net/wan/Kconfig - 1.5 drivers/net/wan/c101.c - 1.2 drivers/net/wan/comx-hw-munich.c - 1.2 drivers/net/wan/comx-proto-lapb.c - 1.2 drivers/net/wan/dlci.c - 1.2 drivers/net/wan/dscc4.c - 1.2 drivers/net/wan/farsync.c - 1.3 drivers/net/wan/hd6457x.c - 1.2 drivers/net/wan/hdlc_cisco.c - 1.2 drivers/net/wan/hdlc_fr.c - 1.2 drivers/net/wan/hdlc_generic.c - 1.2 drivers/net/wan/hdlc_ppp.c - 1.2 drivers/net/wan/hdlc_raw.c - 1.2 drivers/net/wan/hdlc_raw_eth.c - 1.2 drivers/net/wan/hdlc_x25.c - 1.2 drivers/net/wan/hostess_sv11.c - 1.2 drivers/net/wan/lapbether.c - 1.3 drivers/net/wan/n2.c - 1.2 drivers/net/wan/pc300.h - 1.2 drivers/net/wan/pc300_drv.c - 1.4 drivers/net/wan/pc300_tty.c - 1.3 drivers/net/wan/sbni.c - 1.2 drivers/net/wan/sdla.c - 1.2 drivers/net/wan/sdladrv.c - 1.2 drivers/net/wan/sdlamain.c - 1.2 drivers/net/wan/sealevel.c - 1.2 drivers/net/wan/wanxl.c - 1.2 drivers/net/wan/x25_asy.c - 1.3 drivers/net/wireless/Kconfig - 1.4 drivers/net/wireless/airo.c - 1.4 drivers/net/wireless/airo_cs.c - 1.3 drivers/net/wireless/netwave_cs.c - 1.3 drivers/net/wireless/orinoco.c - 1.2 drivers/net/wireless/ray_cs.c - 1.4 drivers/net/wireless/strip.c - 1.3 drivers/net/wireless/wavelan_cs.c - 1.4 drivers/net/wireless/wl3501_cs.c - 1.4 drivers/net/zorro8390.c - 1.4 drivers/oprofile/timer_int.c - 1.2 drivers/parisc/Kconfig - 1.4 drivers/parisc/dino.c - 1.4 drivers/parport/Kconfig - 1.2 drivers/parport/Makefile - 1.2 drivers/parport/daisy.c - 1.3 drivers/parport/ieee1284.c - 1.2 drivers/parport/ieee1284_ops.c - 1.2 drivers/parport/init.c - 1.2 drivers/parport/parport_amiga.c - 1.2 drivers/parport/parport_arc.c - 1.2 drivers/parport/parport_atari.c - 1.2 drivers/parport/parport_gsc.c - 1.3 drivers/parport/parport_mfc3.c - 1.2 drivers/parport/parport_pc.c - 1.3 drivers/parport/parport_sunbpp.c - 1.3 drivers/parport/probe.c - 1.2 drivers/parport/procfs.c - 1.2 drivers/parport/share.c - 1.3 drivers/pci/hotplug.c - 1.3 drivers/pci/hotplug/Kconfig - 1.2 drivers/pci/hotplug/Makefile - 1.2 drivers/pci/hotplug/cpqphp.h - 1.2 drivers/pci/hotplug/cpqphp_core.c - 1.2 drivers/pci/hotplug/cpqphp_ctrl.c - 1.3 drivers/pci/hotplug/cpqphp_pci.c - 1.3 drivers/pci/hotplug/cpqphp_sysfs.c - 1.2 drivers/pci/hotplug/pci_hotplug.h - 1.3 drivers/pci/hotplug/pci_hotplug_core.c - 1.3 drivers/pci/pci.c - 1.2 drivers/pci/pci.ids - 1.6 drivers/pci/probe.c - 1.7 drivers/pci/quirks.c - 1.3 drivers/pci/setup-bus.c - 1.2 drivers/pci/setup-res.c - 1.3 drivers/pcmcia/sa1100_neponset.c - 1.2 drivers/pcmcia/sa1111_generic.c - 1.2 drivers/pcmcia/sa1111_generic.h - 1.2 drivers/pcmcia/sa11xx_core.c - 1.2 drivers/pcmcia/sa11xx_core.h - 1.2 drivers/s390/Kconfig - 1.2 drivers/s390/block/Kconfig - 1.2 drivers/s390/block/Makefile - 1.2 drivers/s390/block/dasd.c - 1.3 drivers/s390/block/dasd_3990_erp.c - 1.3 drivers/s390/block/dasd_eckd.c - 1.3 drivers/s390/block/dasd_genhd.c - 1.3 drivers/s390/block/dasd_int.h - 1.3 drivers/s390/block/dasd_ioctl.c - 1.2 drivers/s390/block/dasd_proc.c - 1.3 drivers/s390/block/xpram.c - 1.2 drivers/s390/char/Makefile - 1.3 drivers/s390/char/con3215.c - 1.3 drivers/s390/char/sclp.c - 1.3 drivers/s390/char/sclp_tty.c - 1.4 drivers/s390/char/sclp_vt220.c - 1.2 drivers/s390/char/tape.h - 1.3 drivers/s390/char/tape_block.c - 1.3 drivers/s390/char/tape_char.c - 1.3 drivers/s390/char/tape_core.c - 1.3 drivers/s390/cio/Makefile - 1.2 drivers/s390/cio/blacklist.c - 1.3 drivers/s390/cio/ccwgroup.c - 1.3 drivers/s390/cio/chsc.c - 1.3 drivers/s390/cio/chsc.h - 1.3 drivers/s390/cio/cio.c - 1.3 drivers/s390/cio/cio.h - 1.3 drivers/s390/cio/css.c - 1.3 drivers/s390/cio/css.h - 1.3 drivers/s390/cio/device.c - 1.4 drivers/s390/cio/device.h - 1.3 drivers/s390/cio/device_fsm.c - 1.3 drivers/s390/cio/device_id.c - 1.3 drivers/s390/cio/device_ops.c - 1.3 drivers/s390/cio/device_pgid.c - 1.3 drivers/s390/cio/device_status.c - 1.3 drivers/s390/cio/qdio.c - 1.3 drivers/s390/net/Kconfig - 1.2 drivers/s390/net/Makefile - 1.2 drivers/s390/net/ctcmain.c - 1.3 drivers/s390/net/ctctty.c - 1.4 drivers/s390/net/iucv.c - 1.3 drivers/s390/net/iucv.h - 1.3 drivers/s390/net/lcs.c - 1.3 drivers/s390/net/netiucv.c - 1.3 drivers/s390/net/qeth.c - 1.4 drivers/s390/s390mach.c - 1.3 drivers/s390/scsi/zfcp_aux.c - 1.3 drivers/s390/scsi/zfcp_ccw.c - 1.3 drivers/s390/scsi/zfcp_def.h - 1.3 drivers/s390/scsi/zfcp_erp.c - 1.3 drivers/s390/scsi/zfcp_ext.h - 1.3 drivers/s390/scsi/zfcp_fsf.c - 1.3 drivers/s390/scsi/zfcp_fsf.h - 1.3 drivers/s390/scsi/zfcp_qdio.c - 1.3 drivers/s390/scsi/zfcp_scsi.c - 1.3 drivers/s390/scsi/zfcp_sysfs_adapter.c - 1.3 drivers/s390/scsi/zfcp_sysfs_driver.c - 1.2 drivers/s390/scsi/zfcp_sysfs_port.c - 1.3 drivers/s390/scsi/zfcp_sysfs_unit.c - 1.3 drivers/sbus/char/aurora.c - 1.2 drivers/sbus/char/vfc_dev.c - 1.3 drivers/scsi/53c700.c - 1.2 drivers/scsi/53c700.h - 1.3 drivers/scsi/BusLogic.c - 1.5 drivers/scsi/Kconfig - 1.6 drivers/scsi/NCR5380.c - 1.2 drivers/scsi/NCR53C9x.c - 1.2 drivers/scsi/NCR53C9x.h - 1.3 drivers/scsi/aacraid/Makefile - 1.2 drivers/scsi/aacraid/aacraid.h - 1.4 drivers/scsi/aacraid/linit.c - 1.4 drivers/scsi/aacraid/rx.c - 1.3 drivers/scsi/aacraid/sa.c - 1.3 drivers/scsi/aic7xxx/aic79xx_osm.c - 1.4 drivers/scsi/aic7xxx/aic7xxx_osm.c - 1.4 drivers/scsi/ata_piix.c - 1.4 drivers/scsi/blz1230.c - 1.2 drivers/scsi/blz2060.c - 1.2 drivers/scsi/cpqfcTSworker.c - 1.2 drivers/scsi/cyberstorm.c - 1.2 drivers/scsi/cyberstormII.c - 1.2 drivers/scsi/dec_esp.c - 1.2 drivers/scsi/fastlane.c - 1.2 drivers/scsi/g_NCR5380.c - 1.3 drivers/scsi/ide-scsi.c - 1.3 drivers/scsi/ini9100u.c - 1.4 drivers/scsi/jazz_esp.c - 1.2 drivers/scsi/libata-core.c - 1.5 drivers/scsi/libata-scsi.c - 1.4 drivers/scsi/libata.h - 1.4 drivers/scsi/mac_esp.c - 1.3 drivers/scsi/mca_53c9x.c - 1.2 drivers/scsi/oktagon_esp.c - 1.2 drivers/scsi/qla1280.c - 1.3 drivers/scsi/qlogicfc.c - 1.4 drivers/scsi/qlogicpti.c - 1.4 drivers/scsi/sata_promise.c - 1.4 drivers/scsi/sata_sil.c - 1.4 drivers/scsi/sata_svw.c - 1.4 drivers/scsi/sata_via.c - 1.4 drivers/scsi/scsi.c - 1.4 drivers/scsi/scsi.h - 1.2 drivers/scsi/scsi_debug.c - 1.3 drivers/scsi/scsi_lib.c - 1.3 drivers/scsi/scsi_priv.h - 1.3 drivers/scsi/sd.c - 1.3 drivers/scsi/sr.c - 1.5 drivers/scsi/st.c - 1.5 drivers/scsi/sun3x_esp.c - 1.2 drivers/scsi/tmscsim.c - 1.3 drivers/serial/68360serial.c - 1.2 drivers/serial/8250.c - 1.10 drivers/serial/8250_pci.c - 1.3 drivers/serial/8250_pnp.c - 1.5 drivers/serial/Kconfig - 1.3 drivers/serial/Makefile - 1.2 drivers/serial/clps711x.c - 1.2 drivers/serial/mcfserial.c - 1.2 drivers/serial/pmac_zilog.c - 1.4 drivers/serial/pmac_zilog.h - 1.2 drivers/serial/serial_core.c - 1.6 drivers/tc/zs.c - 1.2 drivers/telephony/ixj.h - 1.2 drivers/usb/class/usblp.c - 1.3 drivers/usb/core/buffer.c - 1.3 drivers/usb/core/hcd-pci.c - 1.2 drivers/usb/core/hcd.c - 1.4 drivers/usb/core/hcd.h - 1.3 drivers/usb/core/hub.c - 1.5 drivers/usb/core/message.c - 1.4 drivers/usb/core/usb.c - 1.5 drivers/usb/gadget/inode.c - 1.3 drivers/usb/gadget/net2280.c - 1.4 drivers/usb/host/ehci-dbg.c - 1.3 drivers/usb/host/ehci-hcd.c - 1.4 drivers/usb/host/ehci-hub.c - 1.3 drivers/usb/host/ehci-mem.c - 1.3 drivers/usb/host/ehci-q.c - 1.3 drivers/usb/host/ehci-sched.c - 1.3 drivers/usb/host/ehci.h - 1.3 drivers/usb/host/ohci-dbg.c - 1.3 drivers/usb/host/ohci-hcd.c - 1.5 drivers/usb/host/ohci-mem.c - 1.2 drivers/usb/host/ohci-pci.c - 1.3 drivers/usb/host/ohci-q.c - 1.4 drivers/usb/host/ohci-sa1111.c - 1.3 drivers/usb/host/ohci.h - 1.3 drivers/usb/host/uhci-debug.c - 1.2 drivers/usb/host/uhci-hcd.c - 1.5 drivers/usb/host/uhci-hcd.h - 1.3 drivers/usb/host/uhci-hub.c - 1.2 drivers/usb/media/stv680.c - 1.2 drivers/usb/misc/speedtch.c - 1.2 drivers/usb/misc/usbtest.c - 1.3 drivers/usb/misc/uss720.c - 1.3 drivers/usb/net/catc.c - 1.2 drivers/usb/net/kaweth.c - 1.2 drivers/usb/net/pegasus.c - 1.2 drivers/usb/net/rtl8150.c - 1.2 drivers/usb/net/usbnet.c - 1.5 drivers/usb/serial/ftdi_sio.c - 1.4 drivers/usb/serial/ftdi_sio.h - 1.4 drivers/usb/serial/keyspan.h - 1.3 drivers/usb/serial/safe_serial.c - 1.2 drivers/usb/storage/sddr09.c - 1.4 drivers/usb/storage/transport.c - 1.4 drivers/usb/storage/unusual_devs.h - 1.6 drivers/video/Kconfig - 1.7 drivers/video/Makefile - 1.5 drivers/video/acornfb.c - 1.2 drivers/video/acornfb.h - 1.2 drivers/video/amifb.c - 1.2 drivers/video/console/fbcon.c - 1.6 drivers/video/console/promcon.c - 1.2 drivers/video/console/sticon.c - 1.2 drivers/video/console/vgacon.c - 1.2 drivers/video/cvisionppc.h - 1.2 drivers/video/fbmem.c - 1.7 drivers/video/ffb.c - 1.2 drivers/video/i810/Makefile - 1.2 drivers/video/pm2fb.c - 1.2 drivers/video/riva/fbdev.c - 1.5 drivers/video/softcursor.c - 1.3 drivers/video/tdfxfb.c - 1.2 fs/Kconfig - 1.7 fs/Kconfig.binfmt - 1.3 fs/Makefile - 1.3 fs/adfs/adfs.h - 1.2 fs/adfs/super.c - 1.2 fs/afs/inode.c - 1.3 fs/afs/super.c - 1.3 fs/aio.c - 1.2 fs/autofs4/inode.c - 1.2 fs/befs/Makefile - 1.2 fs/befs/linuxvfs.c - 1.2 fs/binfmt_elf.c - 1.5 fs/binfmt_flat.c - 1.2 fs/binfmt_misc.c - 1.2 fs/block_dev.c - 1.4 fs/buffer.c - 1.4 fs/coda/inode.c - 1.2 fs/compat.c - 1.3 fs/compat_ioctl.c - 1.6 fs/cramfs/inode.c - 1.3 fs/dcache.c - 1.5 fs/devfs/base.c - 1.4 fs/devfs/internal.h - 1.2 fs/devfs/util.c - 1.2 fs/devpts/Makefile - 1.2 fs/devpts/inode.c - 1.2 fs/efs/super.c - 1.2 fs/eventpoll.c - 1.4 fs/exec.c - 1.4 fs/ext2/acl.c - 1.2 fs/ext2/ialloc.c - 1.3 fs/ext2/super.c - 1.3 fs/ext3/acl.c - 1.2 fs/ext3/balloc.c - 1.3 fs/ext3/ialloc.c - 1.3 fs/ext3/super.c - 1.4 fs/fcntl.c - 1.3 fs/file_table.c - 1.4 fs/freevxfs/vxfs_bmap.c - 1.3 fs/freevxfs/vxfs_super.c - 1.4 fs/fs-writeback.c - 1.4 fs/hfs/ChangeLog - 1.2 fs/hfs/FAQ.txt - 1.2 fs/hfs/HFS.txt - 1.2 fs/hfs/INSTALL.txt - 1.2 fs/hfs/Makefile - 1.2 fs/hfs/balloc.c - 1.2 fs/hfs/bdelete.c - 1.2 fs/hfs/bfind.c - 1.2 fs/hfs/bins_del.c - 1.2 fs/hfs/binsert.c - 1.2 fs/hfs/bitmap.c - 1.2 fs/hfs/bitops.c - 1.2 fs/hfs/bnode.c - 1.2 fs/hfs/brec.c - 1.2 fs/hfs/btree.c - 1.2 fs/hfs/catalog.c - 1.2 fs/hfs/dir.c - 1.2 fs/hfs/dir_cap.c - 1.2 fs/hfs/dir_dbl.c - 1.2 fs/hfs/dir_nat.c - 1.2 fs/hfs/extent.c - 1.2 fs/hfs/file.c - 1.2 fs/hfs/file_cap.c - 1.2 fs/hfs/file_hdr.c - 1.3 fs/hfs/hfs.h - 1.2 fs/hfs/hfs_btree.h - 1.2 fs/hfs/inode.c - 1.2 fs/hfs/mdb.c - 1.2 fs/hfs/part_tbl.c - 1.2 fs/hfs/string.c - 1.2 fs/hfs/super.c - 1.2 fs/hfs/sysdep.c - 1.2 fs/hfs/trans.c - 1.2 fs/hfs/version.c - 1.2 fs/hpfs/buffer.c - 1.2 fs/hpfs/super.c - 1.2 fs/inode.c - 1.2 fs/intermezzo/dir.c - 1.2 fs/jffs/inode-v23.c - 1.2 fs/jffs2/background.c - 1.2 fs/jfs/acl.c - 1.2 fs/jfs/jfs_acl.h - 1.2 fs/jfs/jfs_dmap.c - 1.2 fs/jfs/jfs_dmap.h - 1.2 fs/jfs/jfs_dtree.c - 1.2 fs/jfs/jfs_dtree.h - 1.2 fs/jfs/jfs_extent.c - 1.2 fs/jfs/jfs_imap.c - 1.3 fs/jfs/jfs_incore.h - 1.2 fs/jfs/jfs_inode.c - 1.2 fs/jfs/jfs_logmgr.c - 1.3 fs/jfs/jfs_logmgr.h - 1.2 fs/jfs/jfs_mount.c - 1.2 fs/jfs/jfs_txnmgr.c - 1.3 fs/jfs/jfs_txnmgr.h - 1.2 fs/jfs/jfs_umount.c - 1.2 fs/jfs/jfs_unicode.c - 1.2 fs/jfs/jfs_unicode.h - 1.2 fs/jfs/jfs_xtree.c - 1.2 fs/jfs/jfs_xtree.h - 1.2 fs/jfs/namei.c - 1.4 fs/jfs/super.c - 1.3 fs/jfs/xattr.c - 1.3 fs/lockd/clntlock.c - 1.2 fs/lockd/clntproc.c - 1.2 fs/lockd/svc.c - 1.2 fs/locks.c - 1.4 fs/namei.c - 1.4 fs/ncpfs/sock.c - 1.2 fs/nfsd/Makefile - 1.2 fs/nfsd/auth.c - 1.2 fs/nfsd/export.c - 1.2 fs/nfsd/nfs3proc.c - 1.2 fs/nfsd/nfs3xdr.c - 1.2 fs/nfsd/nfs4proc.c - 1.2 fs/nfsd/nfs4state.c - 1.2 fs/nfsd/nfs4xdr.c - 1.2 fs/nfsd/nfsctl.c - 1.2 fs/nfsd/nfsfh.c - 1.3 fs/nfsd/nfsproc.c - 1.2 fs/nfsd/nfsxdr.c - 1.3 fs/nfsd/stats.c - 1.2 fs/nfsd/vfs.c - 1.3 fs/open.c - 1.3 fs/openpromfs/inode.c - 1.2 fs/partitions/check.c - 1.3 fs/partitions/efi.c - 1.2 fs/proc/array.c - 1.2 fs/proc/base.c - 1.5 fs/proc/proc_misc.c - 1.5 fs/readdir.c - 1.3 fs/reiserfs/journal.c - 1.4 fs/romfs/inode.c - 1.2 fs/smbfs/file.c - 1.3 fs/smbfs/proc.c - 1.4 fs/smbfs/request.c - 1.2 fs/smbfs/smbiod.c - 1.2 fs/stat.c - 1.4 fs/super.c - 1.3 include/acpi/acconfig.h - 1.3 include/acpi/acglobal.h - 1.3 include/acpi/acpixf.h - 1.3 include/acpi/actypes.h - 1.3 include/acpi/acutils.h - 1.3 include/asm-alpha/param.h - 1.2 include/asm-alpha/semaphore.h - 1.2 include/asm-alpha/stat.h - 1.2 include/asm-alpha/termbits.h - 1.2 include/asm-alpha/unistd.h - 1.2 include/asm-arm/arch-cl7500/acornfb.h - 1.2 include/asm-arm/arch-rpc/acornfb.h - 1.2 include/asm-arm/atomic.h - 1.2 include/asm-arm/cacheflush.h - 1.3 include/asm-arm/dma-mapping.h - 1.2 include/asm-arm/glue.h - 1.2 include/asm-arm/hardware/sa1111.h - 1.3 include/asm-arm/locks.h - 1.2 include/asm-arm/page.h - 1.2 include/asm-arm/param.h - 1.2 include/asm-arm/pci.h - 1.4 include/asm-arm/proc-fns.h - 1.2 include/asm-arm/shmparam.h - 1.2 include/asm-arm/spinlock.h - 1.2 include/asm-arm/system.h - 1.2 include/asm-arm/termbits.h - 1.2 include/asm-arm/tlb.h - 1.2 include/asm-arm/unistd.h - 1.4 include/asm-arm26/cache.h - 1.2 include/asm-arm26/module.h - 1.2 include/asm-arm26/param.h - 1.2 include/asm-arm26/termbits.h - 1.2 include/asm-arm26/unistd.h - 1.2 include/asm-cris/param.h - 1.2 include/asm-cris/termbits.h - 1.2 include/asm-cris/unistd.h - 1.2 include/asm-generic/tlb.h - 1.2 include/asm-h8300/aki3068net/machine-depend.h - 1.2 include/asm-h8300/h8300_ne.h - 1.2 include/asm-h8300/h8max/machine-depend.h - 1.2 include/asm-h8300/ide.h - 1.2 include/asm-h8300/io.h - 1.3 include/asm-h8300/module.h - 1.2 include/asm-h8300/page.h - 1.2 include/asm-h8300/param.h - 1.2 include/asm-h8300/processor.h - 1.2 include/asm-h8300/system.h - 1.2 include/asm-h8300/termbits.h - 1.2 include/asm-h8300/unistd.h - 1.2 include/asm-i386/acpi.h - 1.4 include/asm-i386/cpufeature.h - 1.2 include/asm-i386/fixmap.h - 1.2 include/asm-i386/linkage.h - 1.2 include/asm-i386/mmzone.h - 1.3 include/asm-i386/module.h - 1.2 include/asm-i386/param.h - 1.2 include/asm-i386/processor.h - 1.3 include/asm-i386/smp.h - 1.3 include/asm-i386/spinlock.h - 1.2 include/asm-i386/termbits.h - 1.2 include/asm-i386/thread_info.h - 1.2 include/asm-i386/timer.h - 1.3 include/asm-i386/timex.h - 1.2 include/asm-i386/unistd.h - 1.3 include/asm-i386/xor.h - 1.2 include/asm-ia64/acpi.h - 1.4 include/asm-ia64/iosapic.h - 1.3 include/asm-ia64/mmu_context.h - 1.4 include/asm-ia64/page.h - 1.4 include/asm-ia64/param.h - 1.3 include/asm-ia64/pci.h - 1.4 include/asm-ia64/perfmon_default_smpl.h - 1.2 include/asm-ia64/processor.h - 1.5 include/asm-ia64/scatterlist.h - 1.3 include/asm-ia64/sn/clksupport.h - 1.4 include/asm-ia64/sn/dmamap.h - 1.3 include/asm-ia64/sn/driver.h - 1.4 include/asm-ia64/sn/intr.h - 1.3 include/asm-ia64/sn/io.h - 1.3 include/asm-ia64/sn/ioc4.h - 1.3 include/asm-ia64/sn/ioconfig_bus.h - 1.3 include/asm-ia64/sn/ioerror_handling.h - 1.3 include/asm-ia64/sn/iograph.h - 1.4 include/asm-ia64/sn/leds.h - 1.2 include/asm-ia64/sn/module.h - 1.4 include/asm-ia64/sn/pci/pci_bus_cvlink.h - 1.4 include/asm-ia64/sn/pci/pcibr.h - 1.4 include/asm-ia64/sn/pci/pcibr_private.h - 1.4 include/asm-ia64/sn/sgi.h - 1.4 include/asm-ia64/sn/sn2/sn_private.h - 1.4 include/asm-ia64/sn/sn_sal.h - 1.3 include/asm-ia64/termbits.h - 1.3 include/asm-ia64/tlb.h - 1.3 include/asm-ia64/unistd.h - 1.2 include/asm-m68k/atarihw.h - 1.2 include/asm-m68k/dma-mapping.h - 1.2 include/asm-m68k/irq.h - 1.2 include/asm-m68k/param.h - 1.2 include/asm-m68k/processor.h - 1.3 include/asm-m68k/sbus.h - 1.3 include/asm-m68k/system.h - 1.3 include/asm-m68k/termbits.h - 1.2 include/asm-m68k/unistd.h - 1.2 include/asm-m68knommu/elf.h - 1.2 include/asm-m68knommu/irq.h - 1.2 include/asm-m68knommu/machdep.h - 1.2 include/asm-m68knommu/param.h - 1.2 include/asm-m68knommu/unistd.h - 1.2 include/asm-mips/addrspace.h - 1.2 include/asm-mips/arc/types.h - 1.2 include/asm-mips/asm.h - 1.2 include/asm-mips/asmmacro-32.h - 1.2 include/asm-mips/asmmacro-64.h - 1.2 include/asm-mips/atomic.h - 1.3 include/asm-mips/au1000.h - 1.2 include/asm-mips/au1000_dma.h - 1.2 include/asm-mips/au1000_gpio.h - 1.2 include/asm-mips/au1000_pcmcia.h - 1.2 include/asm-mips/au1000_usbdev.h - 1.2 include/asm-mips/bitops.h - 1.2 include/asm-mips/bootinfo.h - 1.2 include/asm-mips/bug.h - 1.2 include/asm-mips/cache.h - 1.2 include/asm-mips/cacheflush.h - 1.2 include/asm-mips/checksum.h - 1.2 include/asm-mips/cobalt/cobalt.h - 1.2 include/asm-mips/cpu.h - 1.2 include/asm-mips/db1x00.h - 1.2 include/asm-mips/dec/ecc.h - 1.2 include/asm-mips/dec/kn05.h - 1.2 include/asm-mips/dec/prom.h - 1.2 include/asm-mips/dec/rtc-dec.h - 1.2 include/asm-mips/dma-mapping.h - 1.3 include/asm-mips/ds1286.h - 1.2 include/asm-mips/elf.h - 1.2 include/asm-mips/floppy.h - 1.2 include/asm-mips/fpu.h - 1.2 include/asm-mips/galileo-boards/ev64120.h - 1.2 include/asm-mips/galileo-boards/ev64120int.h - 1.2 include/asm-mips/galileo-boards/ev96100.h - 1.2 include/asm-mips/galileo-boards/gt96100.h - 1.2 include/asm-mips/gdb-stub.h - 1.2 include/asm-mips/gt64120.h - 1.2 include/asm-mips/gt64120/gt64120.h - 1.2 include/asm-mips/gt64120/momenco_ocelot/gt64120_dep.h - 1.2 include/asm-mips/hardirq.h - 1.2 include/asm-mips/highmem.h - 1.2 include/asm-mips/hw_irq.h - 1.2 include/asm-mips/i8259.h - 1.2 include/asm-mips/ide.h - 1.2 include/asm-mips/io.h - 1.3 include/asm-mips/ioctl.h - 1.2 include/asm-mips/ip32/crime.h - 1.2 include/asm-mips/ip32/mace.h - 1.2 include/asm-mips/irq.h - 1.2 include/asm-mips/irq_cpu.h - 1.2 include/asm-mips/jazz.h - 1.2 include/asm-mips/jmr3927/ds1742rtc.h - 1.2 include/asm-mips/jmr3927/pci.h - 1.2 include/asm-mips/keyboard.h - 1.2 include/asm-mips/mc146818rtc.h - 1.2 include/asm-mips/mips-boards/atlas.h - 1.2 include/asm-mips/mips-boards/atlasint.h - 1.2 include/asm-mips/mips-boards/bonito64.h - 1.2 include/asm-mips/mips-boards/generic.h - 1.2 include/asm-mips/mips-boards/malta.h - 1.2 include/asm-mips/mips-boards/msc01_pci.h - 1.2 include/asm-mips/mips-boards/piix4.h - 1.2 include/asm-mips/mips-boards/prom.h - 1.2 include/asm-mips/mips-boards/seadint.h - 1.2 include/asm-mips/mipsregs.h - 1.2 include/asm-mips/mmu_context.h - 1.2 include/asm-mips/mmzone.h - 1.3 include/asm-mips/msgbuf.h - 1.2 include/asm-mips/mv64340.h - 1.2 include/asm-mips/namei.h - 1.2 include/asm-mips/page-32.h - 1.2 include/asm-mips/page-64.h - 1.2 include/asm-mips/page.h - 1.2 include/asm-mips/param.h - 1.2 include/asm-mips/pb1000.h - 1.2 include/asm-mips/pb1100.h - 1.2 include/asm-mips/pb1500.h - 1.2 include/asm-mips/pci.h - 1.5 include/asm-mips/pci/bridge.h - 1.2 include/asm-mips/pci_channel.h - 1.2 include/asm-mips/pgalloc.h - 1.2 include/asm-mips/pgtable-32.h - 1.2 include/asm-mips/pgtable-64.h - 1.2 include/asm-mips/pgtable-bits.h - 1.2 include/asm-mips/pgtable.h - 1.2 include/asm-mips/processor.h - 1.2 include/asm-mips/ptrace.h - 1.2 include/asm-mips/r4kcache.h - 1.2 include/asm-mips/rtc.h - 1.2 include/asm-mips/semaphore-helper.h - 1.2 include/asm-mips/semaphore.h - 1.2 include/asm-mips/serial.h - 1.2 include/asm-mips/sgi/ioc.h - 1.2 include/asm-mips/sgialib.h - 1.2 include/asm-mips/sgiarcs.h - 1.2 include/asm-mips/sibyte/board.h - 1.2 include/asm-mips/sibyte/carmel.h - 1.2 include/asm-mips/sibyte/sb1250.h - 1.2 include/asm-mips/sibyte/sentosa.h - 1.2 include/asm-mips/sibyte/swarm.h - 1.2 include/asm-mips/sibyte/trace_prof.h - 1.2 include/asm-mips/sigcontext.h - 1.2 include/asm-mips/siginfo.h - 1.2 include/asm-mips/sim.h - 1.2 include/asm-mips/smp.h - 1.3 include/asm-mips/smplock.h - 1.2 include/asm-mips/sn/addrs.h - 1.2 include/asm-mips/sn/arch.h - 1.2 include/asm-mips/sn/intr.h - 1.2 include/asm-mips/sn/intr_public.h - 1.2 include/asm-mips/sn/klconfig.h - 1.2 include/asm-mips/sn/sn0/addrs.h - 1.2 include/asm-mips/sn/sn0/ip27.h - 1.2 include/asm-mips/sn/sn_private.h - 1.2 include/asm-mips/sni.h - 1.2 include/asm-mips/socket.h - 1.3 include/asm-mips/spinlock.h - 1.2 include/asm-mips/stackframe.h - 1.2 include/asm-mips/system.h - 1.2 include/asm-mips/termbits.h - 1.2 include/asm-mips/termios.h - 1.2 include/asm-mips/thread_info.h - 1.2 include/asm-mips/time.h - 1.2 include/asm-mips/timex.h - 1.2 include/asm-mips/tlb.h - 1.2 include/asm-mips/topology.h - 1.2 include/asm-mips/tx4927/toshiba_rbtx4927.h - 1.2 include/asm-mips/tx4927/tx4927_pci.h - 1.2 include/asm-mips/types.h - 1.2 include/asm-mips/uaccess.h - 1.2 include/asm-mips/unaligned.h - 1.2 include/asm-mips/unistd.h - 1.2 include/asm-mips/vr41xx/mpc30x.h - 1.2 include/asm-mips/vr41xx/vr41xx.h - 1.2 include/asm-mips/vr41xx/vrc4173.h - 1.2 include/asm-mips/vr41xx/workpad.h - 1.2 include/asm-mips/war.h - 1.2 include/asm-parisc/module.h - 1.2 include/asm-parisc/param.h - 1.2 include/asm-parisc/termbits.h - 1.2 include/asm-parisc/unistd.h - 1.3 include/asm-ppc/cache.h - 1.2 include/asm-ppc/machdep.h - 1.3 include/asm-ppc/param.h - 1.3 include/asm-ppc/system.h - 1.2 include/asm-ppc/termbits.h - 1.2 include/asm-ppc/unistd.h - 1.3 include/asm-ppc64/cacheflush.h - 1.2 include/asm-ppc64/iSeries/iSeries_dma.h - 1.3 include/asm-ppc64/iSeries/iSeries_pci.h - 1.3 include/asm-ppc64/io.h - 1.4 include/asm-ppc64/irq.h - 1.3 include/asm-ppc64/lmb.h - 1.3 include/asm-ppc64/machdep.h - 1.4 include/asm-ppc64/mmu.h - 1.4 include/asm-ppc64/mmu_context.h - 1.4 include/asm-ppc64/page.h - 1.3 include/asm-ppc64/param.h - 1.2 include/asm-ppc64/pci.h - 1.5 include/asm-ppc64/pci_dma.h - 1.3 include/asm-ppc64/pgtable.h - 1.4 include/asm-ppc64/processor.h - 1.5 include/asm-ppc64/prom.h - 1.4 include/asm-ppc64/scatterlist.h - 1.2 include/asm-ppc64/signal.h - 1.2 include/asm-ppc64/smp.h - 1.4 include/asm-ppc64/system.h - 1.4 include/asm-ppc64/termbits.h - 1.2 include/asm-ppc64/thread_info.h - 1.2 include/asm-ppc64/tlb.h - 1.3 include/asm-ppc64/tlbflush.h - 1.2 include/asm-ppc64/unistd.h - 1.3 include/asm-s390/byteorder.h - 1.4 include/asm-s390/ccwdev.h - 1.4 include/asm-s390/ccwgroup.h - 1.3 include/asm-s390/compat.h - 1.2 include/asm-s390/debug.h - 1.2 include/asm-s390/dma-mapping.h - 1.2 include/asm-s390/idals.h - 1.3 include/asm-s390/param.h - 1.2 include/asm-s390/pgalloc.h - 1.3 include/asm-s390/qdio.h - 1.2 include/asm-s390/sigp.h - 1.2 include/asm-s390/smp.h - 1.3 include/asm-s390/termbits.h - 1.2 include/asm-s390/unistd.h - 1.3 include/asm-sh/cache.h - 1.3 include/asm-sh/hardirq.h - 1.3 include/asm-sh/kmap_types.h - 1.2 include/asm-sh/param.h - 1.2 include/asm-sh/termbits.h - 1.2 include/asm-sh/unistd.h - 1.3 include/asm-sparc/asmmacro.h - 1.2 include/asm-sparc/atomic.h - 1.3 include/asm-sparc/cache.h - 1.2 include/asm-sparc/checksum.h - 1.2 include/asm-sparc/cprefix.h - 1.2 include/asm-sparc/hardirq.h - 1.2 include/asm-sparc/head.h - 1.2 include/asm-sparc/io.h - 1.3 include/asm-sparc/param.h - 1.2 include/asm-sparc/signal.h - 1.2 include/asm-sparc/system.h - 1.3 include/asm-sparc/termbits.h - 1.2 include/asm-sparc/thread_info.h - 1.3 include/asm-sparc/unistd.h - 1.3 include/asm-sparc/winmacro.h - 1.3 include/asm-sparc64/cache.h - 1.2 include/asm-sparc64/io.h - 1.4 include/asm-sparc64/param.h - 1.2 include/asm-sparc64/signal.h - 1.2 include/asm-sparc64/smp.h - 1.3 include/asm-sparc64/spinlock.h - 1.2 include/asm-sparc64/termbits.h - 1.2 include/asm-sparc64/thread_info.h - 1.2 include/asm-sparc64/unistd.h - 1.3 include/asm-um/linkage.h - 1.2 include/asm-um/param.h - 1.2 include/asm-um/unistd.h - 1.2 include/asm-v850/param.h - 1.2 include/asm-v850/termbits.h - 1.2 include/asm-v850/unistd.h - 1.2 include/asm-x86_64/a.out.h - 1.3 include/asm-x86_64/acpi.h - 1.4 include/asm-x86_64/apic.h - 1.3 include/asm-x86_64/compat.h - 1.2 include/asm-x86_64/cpufeature.h - 1.2 include/asm-x86_64/mmzone.h - 1.2 include/asm-x86_64/msr.h - 1.2 include/asm-x86_64/param.h - 1.2 include/asm-x86_64/pci-direct.h - 1.2 include/asm-x86_64/pci.h - 1.4 include/asm-x86_64/pgtable.h - 1.4 include/asm-x86_64/processor.h - 1.3 include/asm-x86_64/proto.h - 1.3 include/asm-x86_64/segment.h - 1.2 include/asm-x86_64/smp.h - 1.4 include/asm-x86_64/system.h - 1.4 include/asm-x86_64/termbits.h - 1.2 include/asm-x86_64/unistd.h - 1.4 include/linux/acpi.h - 1.3 include/linux/aio.h - 1.2 include/linux/bitmap.h - 1.4 include/linux/blkdev.h - 1.5 include/linux/cache.h - 1.2 include/linux/compat.h - 1.4 include/linux/compat_ioctl.h - 1.5 include/linux/compiler-gcc3.h - 1.3 include/linux/compiler.h - 1.4 include/linux/concap.h - 1.2 include/linux/console.h - 1.7 include/linux/cpu.h - 1.4 include/linux/cpufreq.h - 1.3 include/linux/cpumask.h - 1.5 include/linux/cyclades.h - 1.2 include/linux/devpts_fs.h - 1.2 include/linux/dm-ioctl-v1.h - 1.2 include/linux/dm-ioctl-v4.h - 1.2 include/linux/dm-ioctl.h - 1.2 include/linux/dvb/video.h - 1.2 include/linux/etherdevice.h - 1.2 include/linux/eventpoll.h - 1.3 include/linux/fb.h - 1.5 include/linux/fs.h - 1.5 include/linux/futex.h - 1.2 include/linux/genhd.h - 1.3 include/linux/hdlc.h - 1.2 include/linux/hfs_fs.h - 1.2 include/linux/hfs_fs_i.h - 1.2 include/linux/hfs_fs_sb.h - 1.2 include/linux/hfs_sysdep.h - 1.2 include/linux/i2o-dev.h - 1.2 include/linux/i2o.h - 1.2 include/linux/ide.h - 1.10 include/linux/idr.h - 1.2 include/linux/if_bonding.h - 1.3 include/linux/if_pppvar.h - 1.2 include/linux/inetdevice.h - 1.3 include/linux/init_task.h - 1.3 include/linux/ioctl32.h - 1.2 include/linux/ipv6.h - 1.5 include/linux/ipv6_route.h - 1.2 include/linux/isdn.h - 1.2 include/linux/isdn/capilli.h - 1.2 include/linux/isdn/fsm.h - 1.2 include/linux/isdn_ppp.h - 1.2 include/linux/isdnif.h - 1.2 include/linux/isicom.h - 1.2 include/linux/istallion.h - 1.2 include/linux/jhash.h - 1.2 include/linux/kallsyms.h - 1.2 include/linux/kernel.h - 1.5 include/linux/lapb.h - 1.2 include/linux/libata.h - 1.4 include/linux/limits.h - 1.2 include/linux/linkage.h - 1.2 include/linux/loop.h - 1.2 include/linux/major.h - 1.2 include/linux/mm.h - 1.5 include/linux/mmzone.h - 1.5 include/linux/modsetver.h - 1.2 include/linux/module.h - 1.3 include/linux/msg.h - 1.2 include/linux/nbd.h - 1.3 include/linux/netdevice.h - 1.6 include/linux/netfilter_bridge.h - 1.3 include/linux/netfilter_ipv4/ip_conntrack_amanda.h - 1.2 include/linux/netfilter_ipv4/ip_nat.h - 1.2 include/linux/netfilter_ipv4/listhelp.h - 1.2 include/linux/netlink.h - 1.2 include/linux/nfs.h - 1.2 include/linux/nfs4.h - 1.3 include/linux/nfsd/auth.h - 1.2 include/linux/nfsd/nfsd.h - 1.2 include/linux/nfsd/nfsfh.h - 1.3 include/linux/nfsd/state.h - 1.2 include/linux/nfsd/syscall.h - 1.2 include/linux/nfsd/xdr4.h - 1.2 include/linux/parport.h - 1.3 include/linux/parport_pc.h - 1.3 include/linux/pci.h - 1.5 include/linux/pci_ids.h - 1.7 include/linux/pmu.h - 1.2 include/linux/ppp.h - 1.2 include/linux/preempt.h - 1.2 include/linux/raid/md_k.h - 1.4 include/linux/raid/raid1.h - 1.2 include/linux/sched.h - 1.5 include/linux/security.h - 1.4 include/linux/sem.h - 1.2 include/linux/serial.h - 1.2 include/linux/serial_core.h - 1.2 include/linux/serial_reg.h - 1.2 include/linux/shm.h - 1.2 include/linux/skbuff.h - 1.4 include/linux/smp.h - 1.3 include/linux/socket.h - 1.2 include/linux/stallion.h - 1.2 include/linux/sunrpc/auth.h - 1.3 include/linux/sunrpc/auth_gss.h - 1.2 include/linux/sunrpc/cache.h - 1.3 include/linux/sunrpc/gss_api.h - 1.3 include/linux/sunrpc/stats.h - 1.2 include/linux/sunrpc/svc.h - 1.2 include/linux/sunrpc/svcauth.h - 1.2 include/linux/suspend.h - 1.3 include/linux/sysctl.h - 1.11 include/linux/sysdev.h - 1.2 include/linux/tty.h - 1.2 include/linux/tty_driver.h - 1.2 include/linux/vt_kern.h - 1.2 include/linux/workqueue.h - 1.2 include/media/tuner.h - 1.3 include/net/addrconf.h - 1.3 include/net/bluetooth/hci.h - 1.4 include/net/bluetooth/hci_core.h - 1.4 include/net/dn_nsp.h - 1.2 include/net/ip6_route.h - 1.2 include/net/ip6_tunnel.h - 1.2 include/net/ip_vs.h - 1.2 include/net/ipip.h - 1.2 include/net/ipv6.h - 1.4 include/net/irda/ali-ircc.h - 1.2 include/net/irda/au1000_ircc.h - 1.2 include/net/irda/crc.h - 1.2 include/net/irda/ircomm_tty.h - 1.4 include/net/irda/irda-usb.h - 1.2 include/net/irda/irda.h - 1.2 include/net/irda/irda_device.h - 1.2 include/net/irda/irias_object.h - 1.2 include/net/irda/irlmp.h - 1.3 include/net/irda/irqueue.h - 1.2 include/net/irda/nsc-ircc.h - 1.2 include/net/irda/smc-ircc.h - 1.2 include/net/irda/timer.h - 1.4 include/net/irda/toshoboe.h - 1.2 include/net/irda/w83977af_ir.h - 1.2 include/net/lapb.h - 1.2 include/net/pkt_sched.h - 1.3 include/net/tcp.h - 1.4 include/scsi/scsi.h - 1.4 include/scsi/scsi_cmnd.h - 1.2 include/video/pm2fb.h - 1.2 include/video/radeon.h - 1.3 init/Kconfig - 1.3 init/Makefile - 1.2 init/do_mounts.h - 1.2 init/do_mounts_devfs.c - 1.2 init/initramfs.c - 1.2 init/main.c - 1.11 ipc/sem.c - 1.3 ipc/shm.c - 1.2 ipc/util.c - 1.3 kernel/Makefile - 1.2 kernel/acct.c - 1.2 kernel/compat.c - 1.3 kernel/exit.c - 1.10 kernel/fork.c - 1.5 kernel/kallsyms.c - 1.7 kernel/kmod.c - 1.4 kernel/module.c - 1.10 kernel/panic.c - 1.2 kernel/pid.c - 1.2 kernel/posix-timers.c - 1.4 kernel/power/disk.c - 1.2 kernel/power/pmdisk.c - 1.3 kernel/power/poweroff.c - 1.2 kernel/power/swsusp.c - 1.4 kernel/printk.c - 1.10 kernel/rcupdate.c - 1.2 kernel/resource.c - 1.3 kernel/sched.c - 1.11 kernel/signal.c - 1.7 kernel/softirq.c - 1.2 kernel/sys.c - 1.5 kernel/sysctl.c - 1.10 kernel/timer.c - 1.3 kernel/uid16.c - 1.2 kernel/workqueue.c - 1.3 lib/crc32.c - 1.3 lib/idr.c - 1.2 lib/kobject.c - 1.4 lib/rwsem-spinlock.c - 1.2 lib/rwsem.c - 1.2 lib/vsprintf.c - 1.4 mm/bootmem.c - 1.2 mm/filemap.c - 1.7 mm/fremap.c - 1.3 mm/highmem.c - 1.3 mm/memory.c - 1.10 mm/mmap.c - 1.6 mm/page_alloc.c - 1.5 mm/pdflush.c - 1.2 mm/rmap.c - 1.3 mm/slab.c - 1.4 mm/swap.c - 1.3 net/8021q/vlan.c - 1.2 net/Kconfig - 1.3 net/appletalk/ddp.c - 1.4 net/atm/clip.c - 1.6 net/atm/lec.c - 1.2 net/atm/lec.h - 1.2 net/bluetooth/Makefile - 1.3 net/bluetooth/af_bluetooth.c - 1.5 net/bluetooth/bnep/core.c - 1.4 net/bluetooth/hci_conn.c - 1.4 net/bluetooth/hci_core.c - 1.4 net/bluetooth/hci_event.c - 1.4 net/bluetooth/hci_proc.c - 1.2 net/bluetooth/l2cap.c - 1.3 net/bluetooth/rfcomm/core.c - 1.4 net/bluetooth/rfcomm/sock.c - 1.3 net/bluetooth/rfcomm/tty.c - 1.4 net/bluetooth/syms.c - 1.2 net/bridge/netfilter/ebt_vlan.c - 1.2 net/compat.c - 1.3 net/core/dev.c - 1.6 net/core/ethtool.c - 1.2 net/core/filter.c - 1.2 net/core/neighbour.c - 1.4 net/core/netfilter.c - 1.2 net/core/pktgen.c - 1.3 net/core/sock.c - 1.4 net/decnet/dn_dev.c - 1.2 net/decnet/dn_nsp_out.c - 1.2 net/decnet/dn_rules.c - 1.2 net/ipv4/af_inet.c - 1.3 net/ipv4/arp.c - 1.4 net/ipv4/devinet.c - 1.4 net/ipv4/esp4.c - 1.2 net/ipv4/fib_rules.c - 1.2 net/ipv4/icmp.c - 1.2 net/ipv4/igmp.c - 1.5 net/ipv4/inetpeer.c - 1.2 net/ipv4/ip_gre.c - 1.2 net/ipv4/ip_output.c - 1.4 net/ipv4/ip_sockglue.c - 1.2 net/ipv4/ipconfig.c - 1.2 net/ipv4/ipip.c - 1.2 net/ipv4/ipmr.c - 1.3 net/ipv4/ipvs/Makefile - 1.2 net/ipv4/ipvs/ip_vs_app.c - 1.2 net/ipv4/ipvs/ip_vs_conn.c - 1.2 net/ipv4/ipvs/ip_vs_core.c - 1.2 net/ipv4/ipvs/ip_vs_ctl.c - 1.2 net/ipv4/ipvs/ip_vs_dh.c - 1.2 net/ipv4/ipvs/ip_vs_ftp.c - 1.2 net/ipv4/ipvs/ip_vs_lblc.c - 1.2 net/ipv4/ipvs/ip_vs_lblcr.c - 1.2 net/ipv4/ipvs/ip_vs_lc.c - 1.2 net/ipv4/ipvs/ip_vs_nq.c - 1.2 net/ipv4/ipvs/ip_vs_proto.c - 1.2 net/ipv4/ipvs/ip_vs_proto_ah.c - 1.2 net/ipv4/ipvs/ip_vs_proto_esp.c - 1.2 net/ipv4/ipvs/ip_vs_proto_icmp.c - 1.2 net/ipv4/ipvs/ip_vs_proto_tcp.c - 1.2 net/ipv4/ipvs/ip_vs_rr.c - 1.2 net/ipv4/ipvs/ip_vs_sched.c - 1.2 net/ipv4/ipvs/ip_vs_sed.c - 1.2 net/ipv4/ipvs/ip_vs_sh.c - 1.2 net/ipv4/ipvs/ip_vs_sync.c - 1.2 net/ipv4/ipvs/ip_vs_wlc.c - 1.2 net/ipv4/ipvs/ip_vs_wrr.c - 1.2 net/ipv4/ipvs/ip_vs_xmit.c - 1.3 net/ipv4/netfilter/ip_conntrack_amanda.c - 1.2 net/ipv4/netfilter/ip_conntrack_core.c - 1.3 net/ipv4/netfilter/ip_conntrack_standalone.c - 1.3 net/ipv4/netfilter/ip_nat_amanda.c - 1.2 net/ipv4/route.c - 1.3 net/ipv4/sysctl_net_ipv4.c - 1.3 net/ipv4/tcp.c - 1.4 net/ipv4/tcp_minisocks.c - 1.2 net/ipv4/udp.c - 1.3 net/ipv4/xfrm4_input.c - 1.2 net/ipv6/addrconf.c - 1.5 net/ipv6/af_inet6.c - 1.4 net/ipv6/esp6.c - 1.2 net/ipv6/exthdrs.c - 1.5 net/ipv6/icmp.c - 1.3 net/ipv6/ip6_fib.c - 1.3 net/ipv6/ip6_input.c - 1.2 net/ipv6/ip6_output.c - 1.5 net/ipv6/ip6_tunnel.c - 1.4 net/ipv6/ipv6_sockglue.c - 1.4 net/ipv6/ipv6_syms.c - 1.2 net/ipv6/mcast.c - 1.5 net/ipv6/ndisc.c - 1.6 net/ipv6/netfilter/ip6_tables.c - 1.4 net/ipv6/netfilter/ip6t_eui64.c - 1.3 net/ipv6/raw.c - 1.4 net/ipv6/route.c - 1.3 net/ipv6/sit.c - 1.3 net/ipv6/sysctl_net_ipv6.c - 1.2 net/ipv6/udp.c - 1.4 net/ipv6/xfrm6_input.c - 1.2 net/ipv6/xfrm6_policy.c - 1.2 net/irda/Makefile - 1.2 net/irda/crc.c - 1.2 net/irda/irda_device.c - 1.2 net/irda/iriap.c - 1.2 net/irda/irias_object.c - 1.2 net/irda/irlan/irlan_common.c - 1.2 net/irda/irlan/irlan_eth.c - 1.2 net/irda/irlap.c - 1.2 net/irda/irlmp.c - 1.3 net/irda/irproc.c - 1.2 net/irda/irqueue.c - 1.2 net/irda/irsyms.c - 1.3 net/irda/irsysctl.c - 1.2 net/irda/irttp.c - 1.2 net/irda/parameters.c - 1.2 net/irda/qos.c - 1.2 net/irda/timer.c - 1.2 net/irda/wrapper.c - 1.2 net/lapb/lapb_iface.c - 1.2 net/lapb/lapb_in.c - 1.2 net/lapb/lapb_out.c - 1.2 net/lapb/lapb_subr.c - 1.2 net/lapb/lapb_timer.c - 1.2 net/rxrpc/connection.c - 1.2 net/sched/Makefile - 1.2 net/sched/cls_api.c - 1.3 net/sched/cls_fw.c - 1.2 net/sched/cls_route.c - 1.2 net/sched/cls_rsvp.h - 1.2 net/sched/cls_tcindex.c - 1.2 net/sched/cls_u32.c - 1.2 net/sched/sch_api.c - 1.2 net/sched/sch_atm.c - 1.3 net/sched/sch_cbq.c - 1.3 net/sched/sch_csz.c - 1.3 net/sched/sch_dsmark.c - 1.3 net/sched/sch_fifo.c - 1.2 net/sched/sch_gred.c - 1.2 net/sched/sch_htb.c - 1.3 net/sched/sch_ingress.c - 1.3 net/sched/sch_prio.c - 1.3 net/sched/sch_red.c - 1.2 net/sched/sch_sfq.c - 1.2 net/sched/sch_tbf.c - 1.3 net/sched/sch_teql.c - 1.3 net/sctp/Kconfig - 1.3 net/sctp/sm_statefuns.c - 1.3 net/sctp/ssnmap.c - 1.3 net/socket.c - 1.3 net/sunrpc/Makefile - 1.2 net/sunrpc/auth.c - 1.3 net/sunrpc/auth_gss/Makefile - 1.2 net/sunrpc/auth_gss/auth_gss.c - 1.3 net/sunrpc/auth_gss/gss_krb5_mech.c - 1.3 net/sunrpc/auth_gss/gss_krb5_seal.c - 1.3 net/sunrpc/auth_gss/gss_mech_switch.c - 1.3 net/sunrpc/auth_gss/sunrpcgss_syms.c - 1.2 net/sunrpc/auth_unix.c - 1.2 net/sunrpc/cache.c - 1.3 net/sunrpc/sched.c - 1.3 net/sunrpc/stats.c - 1.2 net/sunrpc/sunrpc_syms.c - 1.3 net/sunrpc/svc.c - 1.2 net/sunrpc/svcauth.c - 1.2 net/sunrpc/svcauth_unix.c - 1.2 net/sunrpc/xprt.c - 1.3 net/sysctl_net.c - 1.2 net/unix/af_unix.c - 1.4 net/wanrouter/wanmain.c - 1.3 net/wanrouter/wanproc.c - 1.2 net/xfrm/xfrm_user.c - 1.3 scripts/Makefile - 1.7 scripts/Makefile.build - 1.2 scripts/Makefile.modinst - 1.2 scripts/Makefile.modpost - 1.2 scripts/kconfig/Makefile - 1.2 scripts/lxdialog/Makefile - 1.2 scripts/mkspec - 1.3 scripts/modpost.c - 1.5 scripts/modpost.h - 1.2 security/dummy.c - 1.4 security/selinux/Makefile - 1.3 security/selinux/hooks.c - 1.5 security/selinux/selinuxfs.c - 1.3 security/selinux/ss/services.c - 1.4 sound/core/info.c - 1.2 sound/core/seq/seq_dummy.c - 1.3 sound/oss/Kconfig - 1.3 sound/oss/Makefile - 1.2 sound/oss/ac97_plugin_ad1980.c - 1.2 sound/oss/cs46xx_wrapper-24.h - 1.2 sound/oss/dmasound/dac3550a.c - 1.2 sound/oss/emu10k1/cardwi.c - 1.2 sound/oss/i810_audio.c - 1.2 sound/oss/msnd.c - 1.2 sound/oss/os.h - 1.2 sound/oss/sb_audio.c - 1.2 sound/oss/vidc.c - 1.3 sound/oss/vidc.h - 1.2 sound/oss/vidc_fill.S - 1.2 usr/gen_init_cpio.c - 1.3 drivers/usb/media/w9968cf.c - 1.3 Documentation/MSI-HOWTO.txt - 1.2 Documentation/dvb/cards.txt - 1.2 Documentation/dvb/faq.txt - 1.2 Documentation/dvb/firmware.txt - 1.2 drivers/pci/msi.c - 1.3 drivers/media/dvb/frontends/dst.c - 1.3 drivers/char/watchdog/w83627hf_wdt.c - 1.3 drivers/scsi/qla2xxx/qla_init.c - 1.3 drivers/scsi/qla2xxx/qla_isr.c - 1.3 drivers/scsi/qla2xxx/qla_mbx.c - 1.3 drivers/scsi/qla2xxx/qla_os.c - 1.4 drivers/scsi/qla2xxx/qla_os.h - 1.2 drivers/usb/gadget/goku_udc.c - 1.2 drivers/usb/gadget/pxa2xx_udc.c - 1.3 drivers/video/kyro/Makefile - 1.2 include/asm-ppc64/iSeries/vio.h - 1.3 include/asm-ppc64/vio.h - 1.3 drivers/net/wan/pci200syn.c - 1.2 drivers/net/irda/old_belkin-sir.c - 1.3 drivers/net/irda/mcp2120-sir.c - 1.3 drivers/net/irda/girbil-sir.c - 1.3 drivers/net/irda/act200l-sir.c - 1.3 drivers/media/video/ir-kbd-gpio.c - 1.2 drivers/media/dvb/ttpci/av7110_v4l.c - 1.2 drivers/media/dvb/ttpci/av7110_hw.h - 1.2 drivers/media/dvb/ttpci/av7110_hw.c - 1.2 drivers/md/raid6main.c - 1.3 lib/bitmap.c - 1.4 drivers/char/viocons.c - 1.2 drivers/bluetooth/bfusb.c - 1.2 drivers/base/class_simple.c - 1.3 arch/ia64/sn/io/sn2/pcibr/pcibr_reg.c - 1.3 arch/sh/boards/systemh/Makefile - 1.2 arch/sh/boards/snapgear/Makefile - 1.2 arch/ppc64/mm/hash_utils.c - 1.3 arch/ppc64/mm/hash_low.S - 1.4 arch/ppc64/kernel/viopath.c - 1.3 arch/ppc64/kernel/vio.c - 1.3 arch/ppc64/kernel/lparcfg.c - 1.4 drivers/usb/host/ohci-omap.c - 1.3 drivers/ide/ide-generic.c - 1.3 drivers/macintosh/Kconfig - 1.3 net/sched/sch_hfsc.c - 1.2 arch/ppc/syslib/open_pic2.c - 1.2 drivers/pci/msi.h - 1.2 drivers/base/dmapool.c - 1.2 drivers/video/aty/radeon_base.c - 1.3 arch/ppc64/kernel/pmac_time.c - 1.2 arch/ppc64/kernel/pmac_smp.c - 1.2 arch/ppc64/kernel/pmac_setup.c - 1.2 arch/ppc64/kernel/pmac_pci.c - 1.2 arch/ppc64/kernel/pmac_feature.c - 1.2 arch/ppc64/kernel/pSeries_nvram.c - 1.2 arch/ppc64/configs/pSeries_defconfig - 1.2 arch/ppc64/configs/g5_defconfig - 1.2 From owner-linux-xfs@oss.sgi.com Thu Mar 11 23:10:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Mar 2004 23:10:38 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2C7AWKO029814 for ; Thu, 11 Mar 2004 23:10:32 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2C750Th000377 for ; Fri, 12 Mar 2004 01:05:00 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2C74wAL5571528 for ; Fri, 12 Mar 2004 18:04:58 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2C74vsB5571282 for linux-xfs@oss.sgi.com; Fri, 12 Mar 2004 18:04:57 +1100 (EST) Date: Fri, 12 Mar 2004 18:04:57 +1100 (EST) From: Nathan Scott Message-Id: <200403120704.i2C74vsB5571282@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - merge back 2.6 XFS change X-archive-position: 2436 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 360 Lines: 13 Update two calls down to bdev layer, the open/close excl interface changed. Date: Thu Mar 11 23:04:08 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:168327a linux-2.6/xfs_super.c - 1.298 From owner-linux-xfs@oss.sgi.com Fri Mar 12 02:38:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 12 Mar 2004 02:38:26 -0800 (PST) Received: from holomorphy.com (mail@holomorphy.com [207.189.100.168]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2CAc2KO009704 for ; Fri, 12 Mar 2004 02:38:03 -0800 Received: from wli by holomorphy.com with local (Exim 3.36 #1 (Debian)) id 1B1jSr-000545-00; Fri, 12 Mar 2004 02:00:25 -0800 Date: Fri, 12 Mar 2004 02:00:25 -0800 From: William Lee Irwin III To: linux-xfs@oss.sgi.com Subject: xfs recovery oops in 2.6.4-mm1 Message-ID: <20040312100025.GP655@holomorphy.com> Mime-Version: 1.0 Content-type: text/plain Content-Disposition: inline Organization: The Domain of Holomorphy User-Agent: Mutt/1.5.5.1+cvs20040105i Content-Transfer-Encoding: 8bit X-archive-position: 2437 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wli@holomorphy.com Precedence: bulk X-list: linux-xfs Content-Length: 88232 Lines: 464 Console log attached. Remote kernel hacking -level access to the system for debugging can be arranged. -- wli -- Attached file included as plaintext by Ecartis -- -- Desc: e3k.log.64 Script started on Fri Mar 12 00:39:18 2004 $ sscreen -x [?1049h[?7h[?1;4;6l[?1h=(Bspin_lock(0000000000726858) CPU#15 stuck at 005aab8c, owner PC(005aab8c):CPU(a) spin_lock(0000000000726858) CPU#6 stuck at 005aab8c, owner PC(005aab8c):CPU(a) spin_lock(0000000000726858) CPU#14 stuck at 005aab8c, owner PC(005aab8c):CPU(a) spin_lock(0000000000726858) CPU#7 stuck at 005aab8c, owner PC(005aab8c):CPU(a) spin_lock(0000000000726858) CPU#11 stuck at 005aab8c, owner PC(005aab8c):CPU(a) spin_lock(0000000000726858) CPU#6 stuck at 005aab8c, owner PC(005aab8c):CPU(a) spin_lock(0000000000726858) CPU#14 stuck at 005aab8c, owner PC(005aab8c):CPU(a) spin_lock(0000000000726858) CPU#7 stuck at 005aab8c, owner PC(005aab8c):CPU(a) spin_lock(0000000000726858) CPU#15 stuck at 005aab8c, owner PC(005aab8c):CPU(a) spin_lock(0000000000726858) CPU#11 stuck at 005aab8c, owner PC(005aab8c):CPU(a) Button XIR Software Power ON 4-slot Sun Enterprise 3000, No Keyboard OpenBoot 3.2.30, 3840 MB memory installed, Serial #9039287. Copyright 2002 Sun Microsystems, Inc. All rights reserved Ethernet address 8:0:20:89:ed:b7, Host ID: 8089edb7. {6} ok boot net:dhcp root=/dev/nfs nfsroot=/mnt/f/e3k/debian ip=dhcp debug initcall_debug profile=1 Boot device: /sbus@3,0/SUNW,hme@3,8c00000:dhcp File and args: root=/dev/nfs nfsroot=/mnt/f/e3k/debian ip=dhcp debug initcall_debug profile=1 4200 4400 4600 4800 4a00 4c00 4e00 5000 5200 5400 5600 5800 5a00 5c00 5e00 6000 6200 6400 6600 6800 6a00 6c00 6e00 7000 7200 7400 7600 7800 7a00 7c00 7e00 8000 8200 8400 8600 8800 8a00 8c00 8e00 9000 9200 9400 9600 9800 9a00 9c00 9e00 a000 a200 a400 a600 a800 aa00 ac00 ae00 b000 b200 b400 b600 b800 ba00 bc00 be00 c000 c200 c400 c600 c800 ca00 cc00 ce00 d000 d200 d400 d600 d800 da00 dc00 de00 e000 e200 e400 e600 e800 ea00 ec00 ee00 f000 f200 f400 f600 f800 fa00 fc00 fe00 10000 10200 10400 10600 10800 10a00 10c00 10e00 11000 11200 11400 11600 11800 11a00 11c00 11e00 12000 12200 12400 12600 12800 12a00 12c00 12e00 13000 13200 13400 13600 13800 13a00 13c00 13e00 14000 14200 14400 14600 14800 14a00 14c00 14e00 15000 15200 15400 15600 15800 15a00 15c00 15e00 16000 16200 16400 16600 16800 16a00 16c00 16e00 17000 17200 17400 17600 17800 17a00 17c00 17e00 18000 18200 18400 18600 18800 18a00 18c00 18e00 19000 19200 19400 19600 19800 19a00 19c00 19e00 1a000 1a200 1a400 1a600 1a800 1aa00 1ac00 1ae00 1b000 1b200 1b400 1b600 1b800 1ba00 1bc00 1be00 1c000 1c200 1c400 1c600 1c800 1ca00 1cc00 1ce00 1d000 1d200 1d400 1d600 1d800 1da00 1dc00 1de00 1e000 1e200 1e400 1e600 1e800 1ea00 1ec00 1ee00 1f000 1f200 1f400 1f600 1f800 1fa00 1fc00 1fe00 20000 20200 20400 20600 20800 20a00 20c00 20e00 21000 21200 21400 21600 21800 21a00 21c00 21e00 22000 22200 22400 22600 22800 22a00 22c00 22e00 23000 23200 23400 23600 23800 23a00 23c00 23e00 24000 24200 24400 24600 24800 24a00 24c00 24e00 25000 25200 25400 25600 25800 25a00 25c00 25e00 26000 26200 26400 26600 26800 26a00 26c00 26e00 27000 27200 27400 27600 27800 27a00 27c00 27e00 28000 28200 28400 28600 28800 28a00 28c00 28e00 29000 29200 29400 29600 29800 29a00 29c00 29e00 2a000 2a200 2a400 2a600 2a800 2aa00 2ac00 2ae00 2b000 2b200 2b400 2b600 2b800 2ba00 2bc00 2be00 2c000 2c200 2c400 2c600 2c800 2ca00 2cc00 2ce00 2d000 2d200 2d400 2d600 2d800 2da00 2dc00 2de00 2e000 2e200 2e400 2e600 2e800 2ea00 2ec00 2ee00 2f000 2f200 2f400 2f600 2f800 2fa00 2fc00 2fe00 30000 30200 30400 30600 30800 30a00 30c00 30e00 31000 31200 31400 31600 31800 31a00 31c00 31e00 32000 32200 32400 32600 32800 32a00 32c00 32e00 33000 33200 33400 33600 33800 33a00 33c00 33e00 34000 34200 34400 34600 34800 34a00 34c00 34e00 35000 35200 35400 35600 35800 35a00 35c00 35e00 36000 36200 36400 36600 36800 36a00 36c00 36e00 37000 37200 37400 37600 37800 37a00 37c00 37e00 38000 38200 38400 38600 38800 38a00 38c00 38e00 39000 39200 39400 39600 39800 39a00 39c00 39e00 3a000 3a200 3a400 3a600 3a800 3aa00 3ac00 3ae00 3b000 3b200 3b400 3b600 3b800 3ba00 3bc00 3be00 3c000 3c200 3c400 3c600 3c800 3ca00 3cc00 3ce00 3d000 3d200 3d400 3d600 3d800 3da00 3dc00 3de00 3e000 3e200 3e400 3e600 3e800 3ea00 3ec00 3ee00 3f000 3f200 3f400 3f600 3f800 3fa00 3fc00 3fe00 40000 40200 40400 40600 40800 40a00 40c00 40e00 41000 41200 41400 41600 41800 41a00 41c00 41e00 42000 42200 42400 42600 42800 42a00 42c00 42e00 43000 43200 43400 43600 43800 43a00 43c00 43e00 44000 44200 44400 44600 44800 44a00 44c00 44e00 45000 45200 45400 45600 45800 45a00 45c00 45e00 46000 46200 46400 46600 46800 46a00 46c00 46e00 47000 47200 47400 47600 47800 47a00 47c00 47e00 48000 48200 48400 48600 48800 48a00 48c00 48e00 49000 49200 49400 49600 49800 49a00 49c00 49e00 4a000 4a200 4a400 4a600 4a800 4aa00 4ac00 4ae00 4b000 4b200 4b400 4b600 4b800 4ba00 4bc00 4be00 4c000 4c200 4c400 4c600 4c800 4ca00 4cc00 4ce00 4d000 4d200 4d400 4d600 4d800 4da00 4dc00 4de00 4e000 4e200 4e400 4e600 4e800 4ea00 4ec00 4ee00 4f000 4f200 4f400 4f600 4f800 4fa00 4fc00 4fe00 50000 50200 50400 50600 50800 50a00 50c00 50e00 51000 51200 51400 51600 51800 51a00 51c00 51e00 52000 52200 52400 52600 52800 52a00 52c00 52e00 53000 53200 53400 53600 53800 53a00 53c00 53e00 54000 54200 54400 54600 54800 54a00 54c00 54e00 55000 55200 55400 55600 55800 55a00 55c00 55e00 56000 56200 56400 56600 56800 56a00 56c00 56e00 57000 57200 57400 57600 57800 57a00 57c00 57e00 58000 58200 58400 58600 58800 58a00 58c00 58e00 59000 59200 59400 59600 59800 59a00 59c00 59e00 5a000 5a200 5a400 5a600 5a800 5aa00 5ac00 5ae00 5b000 5b200 5b400 5b600 5b800 5ba00 5bc00 5be00 5c000 5c200 5c400 5c600 5c800 5ca00 5cc00 5ce00 5d000 5d200 5d400 5d600 5d800 5da00 5dc00 5de00 5e000 5e200 5e400 5e600 5e800 5ea00 5ec00 5ee00 5f000 5f200 5f400 5f600 5f800 5fa00 5fc00 5fe00 60000 60200 60400 60600 60800 60a00 60c00 60e00 61000 61200 61400 61600 61800 61a00 61c00 61e00 62000 62200 62400 62600 62800 62a00 62c00 62e00 63000 63200 63400 63600 63800 63a00 63c00 63e00 64000 64200 64400 64600 64800 64a00 64c00 64e00 65000 65200 65400 65600 65800 65a00 65c00 65e00 66000 66200 66400 66600 66800 66a00 66c00 66e00 67000 67200 67400 67600 67800 67a00 67c00 67e00 68000 68200 68400 68600 68800 68a00 68c00 68e00 69000 69200 69400 69600 69800 69a00 69c00 69e00 6a000 6a200 6a400 6a600 6a800 6aa00 6ac00 6ae00 6b000 6b200 6b400 6b600 6b800 6ba00 6bc00 6be00 6c000 6c200 6c400 6c600 6c800 6ca00 6cc00 6ce00 6d000 6d200 6d400 6d600 6d800 6da00 6dc00 6de00 6e000 6e200 6e400 6e600 6e800 6ea00 6ec00 6ee00 6f000 6f200 6f400 6f600 6f800 6fa00 6fc00 6fe00 70000 70200 70400 70600 70800 70a00 70c00 70e00 71000 71200 71400 71600 71800 71a00 71c00 71e00 72000 72200 72400 72600 72800 72a00 72c00 72e00 73000 73200 73400 73600 73800 73a00 73c00 73e00 74000 74200 74400 74600 74800 74a00 74c00 74e00 75000 75200 75400 75600 75800 75a00 75c00 75e00 76000 76200 76400 76600 76800 76a00 76c00 76e00 77000 77200 77400 77600 77800 77a00 77c00 77e00 78000 78200 78400 78600 78800 78a00 78c00 78e00 79000 79200 79400 79600 79800 79a00 79c00 79e00 7a000 7a200 7a400 7a600 7a800 7aa00 7ac00 7ae00 7b000 7b200 7b400 7b600 7b800 7ba00 7bc00 7be00 7c000 7c200 7c400 7c600 7c800 7ca00 7cc00 7ce00 7d000 7d200 7d400 7d600 7d800 7da00 7dc00 7de00 7e000 7e200 7e400 7e600 7e800 7ea00 7ec00 7ee00 7f000 7f200 7f400 7f600 7f800 7fa00 7fc00 7fe00 80000 80200 80400 80600 80800 80a00 80c00 80e00 81000 81200 81400 81600 81800 81a00 81c00 81e00 82000 82200 82400 82600 82800 82a00 82c00 82e00 83000 83200 83400 83600 83800 83a00 83c00 83e00 84000 84200 84400 84600 84800 84a00 84c00 84e00 85000 85200 85400 85600 85800 85a00 85c00 85e00 86000 86200 86400 86600 86800 86a00 86c00 86e00 87000 87200 87400 87600 87800 87a00 87c00 87e00 88000 88200 88400 88600 88800 88a00 88c00 88e00 89000 89200 89400 89600 89800 89a00 89c00 89e00 8a000 8a200 8a400 8a600 8a800 8aa00 8ac00 8ae00 8b000 8b200 8b400 8b600 8b800 8ba00 8bc00 8be00 8c000 8c200 8c400 8c600 8c800 8ca00 8cc00 8ce00 8d000 8d200 8d400 8d600 8d800 8da00 8dc00 8de00 8e000 8e200 8e400 8e600 8e800 8ea00 8ec00 8ee00 8f000 8f200 8f400 8f600 8f800 8fa00 8fc00 8fe00 90000 90200 90400 90600 90800 90a00 90c00 90e00 91000 91200 91400 91600 91800 91a00 91c00 91e00 92000 92200 92400 92600 92800 92a00 92c00 92e00 93000 93200 93400 93600 93800 93a00 93c00 93e00 94000 94200 94400 94600 94800 94a00 94c00 94e00 95000 95200 95400 95600 95800 95a00 95c00 95e00 96000 96200 96400 96600 96800 96a00 96c00 96e00 97000 97200 97400 97600 97800 97a00 97c00 97e00 98000 98200 98400 98600 98800 98a00 98c00 98e00 99000 99200 99400 99600 99800 99a00 99c00 99e00 9a000 9a200 9a400 9a600 9a800 9aa00 9ac00 9ae00 9b000 9b200 9b400 9b600 9b800 9ba00 9bc00 9be00 9c000 9c200 9c400 9c600 9c800 9ca00 9cc00 9ce00 9d000 9d200 9d400 9d600 9d800 9da00 9dc00 9de00 9e000 9e200 9e400 9e600 9e800 9ea00 9ec00 9ee00 9f000 9f200 9f400 9f600 9f800 9fa00 9fc00 9fe00 a0000 a0200 a0400 a0600 a0800 a0a00 a0c00 a0e00 a1000 a1200 a1400 a1600 a1800 a1a00 a1c00 a1e00 a2000 a2200 a2400 a2600 a2800 a2a00 a2c00 a2e00 a3000 a3200 a3400 a3600 a3800 a3a00 a3c00 a3e00 a4000 a4200 a4400 a4600 a4800 a4a00 a4c00 a4e00 a5000 a5200 a5400 a5600 a5800 a5a00 a5c00 a5e00 a6000 a6200 a6400 a6600 a6800 a6a00 a6c00 a6e00 a7000 a7200 a7400 a7600 a7800 a7a00 a7c00 a7e00 a8000 a8200 a8400 a8600 a8800 a8a00 a8c00 a8e00 a9000 a9200 a9400 a9600 a9800 a9a00 a9c00 a9e00 aa000 aa200 aa400 aa600 aa800 aaa00 aac00 aae00 ab000 ab200 ab400 ab600 ab800 aba00 abc00 abe00 ac000 ac200 ac400 ac600 ac800 aca00 acc00 ace00 ad000 ad200 ad400 ad600 ad800 ada00 adc00 ade00 ae000 ae200 ae400 ae600 ae800 aea00 aec00 aee00 af000 af200 af400 af600 af800 afa00 afc00 afe00 b0000 b0200 b0400 b0600 b0800 b0a00 b0c00 b0e00 b1000 b1200 b1400 b1600 b1800 b1a00 b1c00 b1e00 b2000 b2200 b2400 b2600 b2800 b2a00 b2c00 b2e00 b3000 b3200 b3400 b3600 b3800 b3a00 b3c00 b3e00 b4000 b4200 b4400 b4600 b4800 b4a00 b4c00 b4e00 b5000 b5200 b5400 b5600 b5800 b5a00 b5c00 b5e00 b6000 b6200 b6400 b6600 b6800 b6a00 b6c00 b6e00 b7000 b7200 b7400 b7600 b7800 b7a00 b7c00 b7e00 b8000 b8200 b8400 b8600 b8800 b8a00 b8c00 b8e00 b9000 b9200 b9400 b9600 b9800 b9a00 b9c00 b9e00 ba000 ba200 ba400 ba600 ba800 baa00 bac00 bae00 bb000 bb200 bb400 bb600 bb800 bba00 bbc00 bbe00 bc000 bc200 bc400 bc600 bc800 bca00 bcc00 bce00 bd000 bd200 bd400 bd600 bd800 bda00 bdc00 bde00 be000 be200 be400 be600 be800 bea00 bec00 bee00 bf000 bf200 bf400 bf600 bf800 bfa00 bfc00 bfe00 c0000 c0200 c0400 c0600 c0800 c0a00 c0c00 c0e00 c1000 c1200 c1400 c1600 c1800 c1a00 c1c00 c1e00 c2000 c2200 c2400 c2600 c2800 c2a00 c2c00 c2e00 c3000 c3200 c3400 c3600 c3800 c3a00 c3c00 c3e00 c4000 c4200 c4400 c4600 c4800 c4a00 c4c00 c4e00 c5000 c5200 c5400 c5600 c5800 c5a00 c5c00 c5e00 c6000 c6200 c6400 c6600 c6800 c6a00 c6c00 c6e00 c7000 c7200 c7400 c7600 c7800 c7a00 c7c00 c7e00 c8000 c8200 c8400 c8600 c8800 c8a00 c8c00 c8e00 c9000 c9200 c9400 c9600 c9800 c9a00 c9c00 c9e00 ca000 ca200 ca400 ca600 ca800 caa00 cac00 cae00 cb000 cb200 cb400 cb600 cb800 cba00 cbc00 cbe00 cc000 cc200 cc400 cc600 cc800 cca00 ccc00 cce00 cd000 cd200 cd400 cd600 cd800 cda00 cdc00 cde00 ce000 ce200 ce400 ce600 ce800 cea00 cec00 cee00 cf000 cf200 cf400 cf600 cf800 cfa00 cfc00 cfe00 d0000 d0200 d0400 d0600 d0800 d0a00 d0c00 d0e00 d1000 d1200 d1400 d1600 d1800 d1a00 d1c00 d1e00 d2000 d2200 d2400 d2600 d2800 d2a00 d2c00 d2e00 d3000 d3200 d3400 d3600 d3800 d3a00 d3c00 d3e00 d4000 d4200 d4400 d4600 d4800 d4a00 d4c00 d4e00 d5000 d5200 d5400 d5600 d5800 d5a00 d5c00 d5e00 d6000 d6200 d6400 d6600 d6800 d6a00 d6c00 d6e00 d7000 d7200 d7400 d7600 d7800 d7a00 d7c00 d7e00 d8000 d8200 d8400 d8600 d8800 d8a00 d8c00 d8e00 d9000 d9200 d9400 d9600 d9800 d9a00 d9c00 d9e00 da000 da200 da400 da600 da800 daa00 dac00 dae00 db000 db200 db400 db600 db800 dba00 dbc00 dbe00 dc000 dc200 dc400 dc600 dc800 dca00 dcc00 dce00 dd000 dd200 dd400 dd600 dd800 dda00 ddc00 dde00 de000 de200 de400 de600 de800 dea00 dec00 dee00 df000 df200 df400 df600 df800 dfa00 dfc00 dfe00 e0000 e0200 e0400 e0600 e0800 e0a00 e0c00 e0e00 e1000 e1200 e1400 e1600 e1800 e1a00 e1c00 e1e00 e2000 e2200 e2400 e2600 e2800 e2a00 e2c00 e2e00 e3000 e3200 e3400 e3600 e3800 e3a00 e3c00 e3e00 e4000 e4200 e4400 e4600 e4800 e4a00 e4c00 e4e00 e5000 e5200 e5400 e5600 e5800 e5a00 e5c00 e5e00 e6000 e6200 e6400 e6600 e6800 e6a00 e6c00 e6e00 e7000 e7200 e7400 e7600 e7800 e7a00 e7c00 e7e00 e8000 e8200 e8400 e8600 e8800 e8a00 e8c00 e8e00 e9000 e9200 e9400 e9600 e9800 e9a00 e9c00 e9e00 ea000 ea200 ea400 ea600 ea800 eaa00 eac00 eae00 eb000 eb200 eb400 eb600 eb800 eba00 ebc00 ebe00 ec000 ec200 ec400 ec600 ec800 eca00 ecc00 ece00 ed000 ed200 ed400 ed600 ed800 eda00 edc00 ede00 ee000 ee200 ee400 ee600 ee800 eea00 eec00 eee00 ef000 ef200 ef400 ef600 ef800 efa00 efc00 efe00 f0000 f0200 f0400 f0600 f0800 f0a00 f0c00 f0e00 f1000 f1200 f1400 f1600 f1800 f1a00 f1c00 f1e00 f2000 f2200 f2400 f2600 f2800 f2a00 f2c00 f2e00 f3000 f3200 f3400 f3600 f3800 f3a00 f3c00 f3e00 f4000 f4200 f4400 f4600 f4800 f4a00 f4c00 f4e00 f5000 f5200 f5400 f5600 f5800 f5a00 f5c00 f5e00 f6000 f6200 f6400 f6600 f6800 f6a00 f6c00 f6e00 f7000 f7200 f7400 f7600 f7800 f7a00 f7c00 f7e00 f8000 f8200 f8400 f8600 f8800 f8a00 f8c00 f8e00 f9000 f9200 f9400 f9600 f9800 f9a00 f9c00 f9e00 fa000 fa200 fa400 fa600 fa800 faa00 fac00 fae00 fb000 fb200 fb400 fb600 fb800 fba00 fbc00 fbe00 fc000 fc200 fc400 fc600 fc800 fca00 fcc00 fce00 fd000 fd200 fd400 fd600 fd800 fda00 fdc00 fde00 fe000 fe200 fe400 fe600 fe800 fea00 fec00 fee00 ff000 ff200 ff400 ff600 ff800 ffa00 ffc00 ffe00 100000 100200 100400 100600 100800 100a00 100c00 100e00 101000 101200 101400 101600 101800 101a00 101c00 101e00 102000 102200 102400 102600 102800 102a00 102c00 102e00 103000 103200 103400 103600 103800 103a00 103c00 103e00 104000 104200 104400 104600 104800 104a00 104c00 104e00 105000 105200 105400 105600 105800 105a00 105c00 105e00 106000 106200 106400 106600 106800 106a00 106c00 106e00 107000 107200 107400 107600 107800 107a00 107c00 107e00 108000 108200 108400 108600 108800 108a00 108c00 108e00 109000 109200 109400 109600 109800 109a00 109c00 109e00 10a000 10a200 10a400 10a600 10a800 10aa00 10ac00 10ae00 10b000 10b200 10b400 10b600 10b800 10ba00 10bc00 10be00 10c000 10c200 10c400 10c600 10c800 10ca00 10cc00 10ce00 10d000 10d200 10d400 10d600 10d800 10da00 10dc00 10de00 10e000 10e200 10e400 10e600 10e800 10ea00 10ec00 10ee00 10f000 10f200 10f400 10f600 10f800 10fa00 10fc00 10fe00 110000 110200 110400 110600 110800 110a00 110c00 110e00 111000 111200 111400 111600 111800 111a00 111c00 111e00 112000 112200 112400 112600 112800 112a00 112c00 112e00 113000 113200 113400 113600 113800 113a00 113c00 113e00 114000 114200 114400 114600 114800 114a00 114c00 114e00 115000 115200 115400 115600 115800 115a00 115c00 115e00 116000 116200 116400 116600 116800 116a00 116c00 116e00 117000 117200 117400 117600 117800 117a00 117c00 117e00 118000 118200 118400 118600 118800 118a00 118c00 118e00 119000 119200 119400 119600 119800 119a00 119c00 119e00 11a000 11a200 11a400 11a600 11a800 11aa00 11ac00 11ae00 11b000 11b200 11b400 11b600 11b800 11ba00 11bc00 11be00 11c000 11c200 11c400 11c600 11c800 11ca00 11cc00 11ce00 11d000 11d200 11d400 11d600 11d800 11da00 11dc00 11de00 11e000 11e200 11e400 11e600 11e800 11ea00 11ec00 11ee00 11f000 11f200 11f400 11f600 11f800 11fa00 11fc00 11fe00 120000 120200 120400 120600 120800 120a00 120c00 120e00 121000 121200 121400 121600 121800 121a00 121c00 121e00 122000 122200 122400 122600 122800 122a00 122c00 122e00 123000 123200 123400 123600 123800 123a00 123c00 123e00 124000 124200 124400 124600 124800 124a00 124c00 124e00 125000 125200 125400 125600 125800 125a00 125c00 125e00 126000 126200 126400 126600 126800 126a00 126c00 126e00 127000 127200 127400 127600 127800 127a00 127c00 127e00 128000 128200 128400 128600 128800 128a00 128c00 128e00 129000 129200 129400 129600 129800 129a00 129c00 129e00 12a000 12a200 12a400 12a600 12a800 12aa00 12ac00 12ae00 12b000 12b200 12b400 12b600 12b800 12ba00 12bc00 12be00 12c000 12c200 12c400 12c600 12c800 12ca00 12cc00 12ce00 12d000 12d200 12d400 12d600 12d800 12da00 12dc00 12de00 12e000 12e200 12e400 12e600 12e800 12ea00 12ec00 12ee00 12f000 12f200 12f400 12f600 12f800 12fa00 12fc00 12fe00 130000 130200 130400 130600 130800 130a00 130c00 130e00 131000 131200 131400 131600 131800 131a00 131c00 131e00 132000 132200 132400 132600 132800 132a00 132c00 132e00 133000 133200 133400 133600 133800 133a00 133c00 133e00 134000 134200 134400 134600 134800 134a00 134c00 134e00 135000 135200 135400 135600 135800 135a00 135c00 135e00 136000 136200 136400 136600 136800 136a00 136c00 136e00 137000 137200 137400 137600 137800 137a00 137c00 137e00 138000 138200 138400 138600 138800 138a00 138c00 138e00 139000 139200 139400 139600 139800 139a00 139c00 139e00 13a000 13a200 13a400 13a600 13a800 13aa00 13ac00 13ae00 13b000 13b200 13b400 13b600 13b800 13ba00 13bc00 13be00 13c000 13c200 13c400 13c600 13c800 13ca00 13cc00 13ce00 13d000 13d200 13d400 13d600 13d800 13da00 13dc00 13de00 13e000 13e200 13e400 13e600 13e800 13ea00 13ec00 13ee00 13f000 13f200 13f400 13f600 13f800 13fa00 13fc00 13fe00 140000 140200 140400 140600 140800 140a00 140c00 140e00 141000 141200 141400 141600 141800 141a00 141c00 141e00 142000 142200 142400 142600 142800 142a00 142c00 142e00 143000 143200 143400 143600 143800 143a00 143c00 143e00 144000 144200 144400 144600 144800 144a00 144c00 144e00 145000 145200 145400 145600 145800 145a00 145c00 145e00 146000 146200 146400 146600 146800 146a00 146c00 146e00 147000 147200 147400 147600 147800 147a00 147c00 147e00 148000 148200 148400 148600 148800 148a00 148c00 148e00 149000 149200 149400 149600 149800 149a00 149c00 149e00 14a000 14a200 14a400 14a600 14a800 14aa00 14ac00 14ae00 14b000 14b200 14b400 14b600 14b800 14ba00 14bc00 14be00 14c000 14c200 14c400 14c600 14c800 14ca00 14cc00 14ce00 14d000 14d200 14d400 14d600 14d800 14da00 14dc00 14de00 14e000 14e200 14e400 14e600 14e800 14ea00 14ec00 14ee00 14f000 14f200 14f400 14f600 14f800 14fa00 14fc00 14fe00 150000 150200 150400 150600 150800 150a00 150c00 150e00 151000 151200 151400 151600 151800 151a00 151c00 151e00 152000 152200 152400 152600 152800 152a00 152c00 152e00 153000 153200 153400 153600 153800 153a00 153c00 153e00 154000 154200 154400 154600 154800 154a00 154c00 154e00 155000 155200 155400 155600 155800 155a00 155c00 155e00 156000 156200 156400 156600 156800 156a00 156c00 156e00 157000 157200 157400 157600 157800 157a00 157c00 157e00 158000 158200 158400 158600 158800 158a00 158c00 158e00 159000 159200 159400 159600 159800 159a00 159c00 159e00 15a000 15a200 15a400 15a600 15a800 15aa00 15ac00 15ae00 15b000 15b200 15b400 15b600 15b800 15ba00 15bc00 15be00 15c000 15c200 15c400 15c600 15c800 15ca00 15cc00 15ce00 15d000 15d200 15d400 15d600 15d800 15da00 15dc00 15de00 15e000 15e200 15e400 15e600 15e800 15ea00 15ec00 15ee00 15f000 15f200 15f400 15f600 15f800 15fa00 15fc00 15fe00 160000 160200 160400 160600 160800 160a00 160c00 160e00 161000 161200 161400 161600 161800 161a00 161c00 161e00 162000 162200 162400 162600 162800 162a00 162c00 162e00 163000 163200 163400 163600 163800 163a00 163c00 163e00 164000 164200 164400 164600 164800 164a00 164c00 164e00 165000 165200 165400 165600 165800 165a00 165c00 165e00 166000 166200 166400 166600 166800 166a00 166c00 166e00 167000 167200 167400 167600 167800 167a00 167c00 167e00 168000 168200 168400 168600 168800 168a00 168c00 168e00 169000 169200 169400 169600 169800 169a00 169c00 169e00 16a000 16a200 16a400 16a600 16a800 16aa00 16ac00 16ae00 16b000 16b200 16b400 16b600 16b800 16ba00 16bc00 16be00 16c000 16c200 16c400 16c600 16c800 16ca00 16cc00 16ce00 16d000 16d200 16d400 16d600 16d800 16da00 16dc00 16de00 16e000 16e200 16e400 16e600 16e800 16ea00 16ec00 16ee00 16f000 16f200 16f400 16f600 16f800 16fa00 16fc00 16fe00 170000 170200 170400 170600 170800 170a00 170c00 170e00 171000 171200 171400 171600 171800 171a00 171c00 171e00 172000 172200 172400 172600 172800 172a00 172c00 172e00 173000 173200 173400 173600 173800 173a00 173c00 173e00 174000 174200 174400 174600 174800 174a00 174c00 174e00 175000 175200 175400 175600 175800 175a00 175c00 175e00 176000 176200 176400 176600 176800 176a00 176c00 176e00 177000 177200 177400 177600 177800 177a00 177c00 177e00 178000 178200 178400 178600 178800 178a00 178c00 178e00 179000 179200 179400 179600 179800 179a00 179c00 179e00 17a000 17a200 17a400 17a600 17a800 17aa00 17ac00 17ae00 17b000 17b200 17b400 17b600 17b800 17ba00 17bc00 17be00 17c000 17c200 17c400 17c600 17c800 17ca00 17cc00 17ce00 17d000 17d200 17d400 17d600 17d800 17da00 17dc00 17de00 17e000 17e200 17e400 17e600 17e800 17ea00 17ec00 17ee00 17f000 17f200 17f400 17f600 17f800 17fa00 17fc00 17fe00 180000 180200 180400 180600 180800 180a00 180c00 180e00 181000 181200 181400 181600 181800 181a00 181c00 181e00 182000 182200 182400 182600 182800 182a00 182c00 182e00 183000 183200 183400 183600 183800 183a00 183c00 183e00 184000 184200 184400 184600 184800 184a00 184c00 184e00 185000 185200 185400 185600 185800 185a00 185c00 185e00 186000 186200 186400 186600 186800 186a00 186c00 186e00 187000 187200 187400 187600 187800 187a00 187c00 187e00 188000 188200 188400 188600 188800 188a00 188c00 188e00 189000 189200 189400 189600 189800 189a00 189c00 189e00 18a000 18a200 18a400 18a600 18a800 18aa00 18ac00 18ae00 18b000 18b200 18b400 18b600 18b800 18ba00 18bc00 18be00 18c000 18c200 18c400 18c600 18c800 18ca00 18cc00 18ce00 18d000 18d200 18d400 18d600 18d800 18da00 18dc00 18de00 18e000 18e200 18e400 18e600 18e800 18ea00 18ec00 18ee00 18f000 18f200 18f400 18f600 18f800 18fa00 18fc00 18fe00 190000 190200 190400 190600 190800 190a00 190c00 190e00 191000 191200 191400 191600 191800 191a00 191c00 191e00 192000 192200 192400 192600 192800 192a00 192c00 192e00 193000 193200 193400 193600 193800 193a00 193c00 193e00 194000 194200 194400 194600 194800 194a00 194c00 194e00 195000 195200 195400 195600 195800 195a00 195c00 195e00 196000 196200 196400 196600 196800 196a00 196c00 196e00 197000 197200 197400 197600 197800 197a00 197c00 197e00 198000 198200 198400 198600 198800 198a00 198c00 198e00 199000 199200 199400 199600 199800 199a00 199c00 199e00 19a000 19a200 19a400 19a600 19a800 19aa00 19ac00 19ae00 19b000 19b200 19b400 19b600 19b800 19ba00 19bc00 19be00 19c000 19c200 19c400 19c600 19c800 19ca00 19cc00 19ce00 19d000 19d200 19d400 19d600 19d800 19da00 19dc00 19de00 19e000 19e200 19e400 19e600 19e800 19ea00 19ec00 19ee00 19f000 19f200 19f400 19f600 19f800 19fa00 19fc00 19fe00 1a0000 1a0200 1a0400 1a0600 1a0800 1a0a00 1a0c00 1a0e00 1a1000 1a1200 1a1400 1a1600 1a1800 1a1a00 1a1c00 1a1e00 1a2000 1a2200 1a2400 1a2600 1a2800 1a2a00 1a2c00 1a2e00 1a3000 1a3200 1a3400 1a3600 1a3800 1a3a00 1a3c00 1a3e00 1a4000 1a4200 1a4400 1a4600 1a4800 1a4a00 1a4c00 1a4e00 1a5000 1a5200 1a5400 1a5600 1a5800 1a5a00 1a5c00 1a5e00 1a6000 1a6200 1a6400 1a6600 1a6800 1a6a00 1a6c00 1a6e00 1a7000 1a7200 1a7400 1a7600 1a7800 1a7a00 1a7c00 1a7e00 1a8000 1a8200 1a8400 1a8600 1a8800 1a8a00 1a8c00 1a8e00 1a9000 1a9200 1a9400 1a9600 1a9800 1a9a00 1a9c00 1a9e00 1aa000 1aa200 1aa400 1aa600 1aa800 1aaa00 1aac00 1aae00 1ab000 1ab200 1ab400 1ab600 1ab800 1aba00 1abc00 1abe00 1ac000 1ac200 1ac400 1ac600 1ac800 1aca00 1acc00 1ace00 1ad000 1ad200 1ad400 1ad600 1ad800 1ada00 1adc00 1ade00 1ae000 1ae200 1ae400 1ae600 1ae800 1aea00 1aec00 1aee00 1af000 1af200 1af400 1af600 1af800 1afa00 1afc00 1afe00 1b0000 1b0200 1b0400 1b0600 1b0800 1b0a00 1b0c00 1b0e00 1b1000 1b1200 1b1400 1b1600 1b1800 1b1a00 1b1c00 1b1e00 1b2000 1b2200 1b2400 1b2600 1b2800 1b2a00 1b2c00 1b2e00 1b3000 1b3200 1b3400 1b3600 1b3800 1b3a00 1b3c00 1b3e00 1b4000 1b4200 1b4400 1b4600 1b4800 1b4a00 1b4c00 1b4e00 1b5000 1b5200 1b5400 1b5600 1b5800 1b5a00 1b5c00 1b5e00 1b6000 1b6200 1b6400 1b6600 1b6800 1b6a00 1b6c00 1b6e00 1b7000 1b7200 1b7400 1b7600 1b7800 1b7a00 1b7c00 1b7e00 1b8000 1b8200 1b8400 1b8600 1b8800 1b8a00 1b8c00 1b8e00 1b9000 1b9200 1b9400 1b9600 1b9800 1b9a00 1b9c00 1b9e00 1ba000 1ba200 1ba400 1ba600 1ba800 1baa00 1bac00 1bae00 1bb000 1bb200 1bb400 1bb600 1bb800 1bba00 1bbc00 1bbe00 1bc000 1bc200 1bc400 1bc600 1bc800 1bca00 1bcc00 1bce00 1bd000 1bd200 1bd400 1bd600 1bd800 1bda00 1bdc00 1bde00 1be000 1be200 1be400 1be600 1be800 1bea00 1bec00 1bee00 1bf000 1bf200 1bf400 1bf600 1bf800 1bfa00 1bfc00 1bfe00 1c0000 1c0200 1c0400 1c0600 1c0800 1c0a00 1c0c00 1c0e00 1c1000 1c1200 1c1400 1c1600 1c1800 1c1a00 1c1c00 1c1e00 1c2000 1c2200 1c2400 1c2600 1c2800 1c2a00 1c2c00 1c2e00 1c3000 1c3200 1c3400 1c3600 1c3800 1c3a00 1c3c00 1c3e00 1c4000 1c4200 1c4400 1c4600 1c4800 1c4a00 1c4c00 1c4e00 1c5000 1c5200 1c5400 1c5600 1c5800 1c5a00 1c5c00 1c5e00 1c6000 1c6200 1c6400 1c6600 1c6800 1c6a00 1c6c00 1c6e00 1c7000 1c7200 1c7400 1c7600 1c7800 1c7a00 1c7c00 1c7e00 1c8000 1c8200 1c8400 1c8600 1c8800 1c8a00 1c8c00 1c8e00 1c9000 1c9200 1c9400 1c9600 1c9800 1c9a00 1c9c00 1c9e00 1ca000 1ca200 1ca400 1ca600 1ca800 1caa00 1cac00 1cae00 1cb000 1cb200 1cb400 1cb600 1cb800 1cba00 1cbc00 1cbe00 1cc000 1cc200 1cc400 1cc600 1cc800 1cca00 1ccc00 1cce00 1cd000 1cd200 1cd400 1cd600 1cd800 1cda00 1cdc00 1cde00 1ce000 1ce200 1ce400 1ce600 1ce800 1cea00 1cec00 1cee00 1cf000 1cf200 1cf400 1cf600 1cf800 1cfa00 1cfc00 1cfe00 1d0000 1d0200 1d0400 1d0600 1d0800 1d0a00 1d0c00 1d0e00 1d1000 1d1200 1d1400 1d1600 1d1800 1d1a00 1d1c00 1d1e00 1d2000 1d2200 1d2400 1d2600 1d2800 1d2a00 1d2c00 1d2e00 1d3000 1d3200 1d3400 1d3600 1d3800 1d3a00 1d3c00 1d3e00 1d4000 1d4200 1d4400 1d4600 1d4800 1d4a00 1d4c00 1d4e00 1d5000 1d5200 1d5400 1d5600 1d5800 1d5a00 1d5c00 1d5e00 1d6000 1d6200 1d6400 1d6600 1d6800 1d6a00 1d6c00 1d6e00 1d7000 1d7200 1d7400 1d7600 1d7800 1d7a00 1d7c00 1d7e00 1d8000 1d8200 1d8400 1d8600 1d8800 1d8a00 1d8c00 1d8e00 1d9000 1d9200 1d9400 1d9600 1d9800 1d9a00 1d9c00 1d9e00 1da000 1da200 1da400 1da600 1da800 1daa00 1dac00 1dae00 1db000 1db200 1db400 1db600 1db800 1dba00 1dbc00 1dbe00 1dc000 1dc200 1dc400 1dc600 1dc800 1dca00 1dcc00 1dce00 1dd000 1dd200 1dd400 1dd600 1dd800 1dda00 1ddc00 1dde00 1de000 1de200 1de400 1de600 1de800 1dea00 1dec00 1dee00 1df000 1df200 1df400 1df600 1df800 1dfa00 1dfc00 1dfe00 1e0000 1e0200 1e0400 1e0600 1e0800 1e0a00 1e0c00 1e0e00 1e1000 1e1200 1e1400 1e1600 1e1800 1e1a00 1e1c00 1e1e00 1e2000 1e2200 1e2400 1e2600 1e2800 1e2a00 1e2c00 1e2e00 1e3000 1e3200 1e3400 1e3600 1e3800 1e3a00 1e3c00 1e3e00 1e4000 1e4200 1e4400 1e4600 1e4800 1e4a00 1e4c00 1e4e00 1e5000 1e5200 1e5400 1e5600 1e5800 1e5a00 1e5c00 1e5e00 1e6000 1e6200 1e6400 1e6600 1e6800 1e6a00 1e6c00 1e6e00 1e7000 1e7200 1e7400 1e7600 1e7800 1e7a00 1e7c00 1e7e00 1e8000 1e8200 1e8400 1e8600 1e8800 1e8a00 1e8c00 1e8e00 1e9000 1e9200 1e9400 1e9600 1e9800 1e9a00 1e9c00 1e9e00 1ea000 1ea200 1ea400 1ea600 1ea800 1eaa00 1eac00 1eae00 1eb000 1eb200 1eb400 1eb600 1eb800 1eba00 1ebc00 1ebe00 1ec000 1ec200 1ec400 1ec600 1ec800 1eca00 1ecc00 1ece00 1ed000 1ed200 1ed400 1ed600 1ed800 1eda00 1edc00 1ede00 1ee000 1ee200 1ee400 1ee600 1ee800 1eea00 1eec00 1eee00 1ef000 1ef200 1ef400 1ef600 1ef800 1efa00 1efc00 1efe00 1f0000 1f0200 1f0400 1f0600 1f0800 1f0a00 1f0c00 1f0e00 1f1000 1f1200 1f1400 1f1600 1f1800 1f1a00 1f1c00 1f1e00 1f2000 1f2200 1f2400 1f2600 1f2800 1f2a00 1f2c00 1f2e00 1f3000 1f3200 1f3400 1f3600 1f3800 1f3a00 1f3c00 1f3e00 1f4000 1f4200 1f4400 1f4600 1f4800 1f4a00 1f4c00 1f4e00 1f5000 1f5200 1f5400 1f5600 1f5800 1f5a00 1f5c00 1f5e00 1f6000 1f6200 1f6400 1f6600 1f6800 1f6a00 1f6c00 1f6e00 1f7000 1f7200 1f7400 1f7600 1f7800 1f7a00 1f7c00 1f7e00 1f8000 1f8200 1f8400 1f8600 1f8800 1f8a00 1f8c00 1f8e00 1f9000 1f9200 1f9400 1f9600 1f9800 1f9a00 1f9c00 1f9e00 1fa000 1fa200 1fa400 1fa600 1fa800 1faa00 1fac00 1fae00 1fb000 1fb200 1fb400 1fb600 1fb800 1fba00 1fbc00 1fbe00 1fc000 1fc200 1fc400 1fc600 1fc800 1fca00 1fcc00 1fce00 1fd000 1fd200 1fd400 1fd600 1fd800 1fda00 1fdc00 1fde00 1fe000 1fe200 1fe400 1fe600 1fe800 1fea00 1fec00 1fee00 1ff000 1ff200 1ff400 1ff600 1ff800 1ffa00 1ffc00 1ffe00 200000 200200 200400 200600 200800 200a00 200c00 200e00 201000 201200 201400 201600 201800 201a00 201c00 201e00 202000 202200 202400 202600 202800 202a00 202c00 202e00 203000 203200 203400 203600 203800 203a00 203c00 203e00 204000 204200 204400 204600 204800 204a00 204c00 204e00 205000 205200 205400 205600 205800 205a00 205c00 205e00 206000 206200 206400 206600 206800 206a00 206c00 206e00 207000 207200 207400 207600 207800 207a00 207c00 207e00 208000 208200 208400 208600 208800 208a00 208c00 208e00 209000 209200 209400 209600 209800 209a00 209c00 209e00 20a000 20a200 20a400 20a600 20a800 20aa00 20ac00 20ae00 20b000 20b200 20b400 20b600 20b800 20ba00 20bc00 20be00 20c000 20c200 20c400 20c600 20c800 20ca00 20cc00 20ce00 20d000 20d200 20d400 20d600 20d800 20da00 20dc00 20de00 20e000 20e200 20e400 20e600 20e800 20ea00 20ec00 20ee00 20f000 20f200 20f400 20f600 20f800 20fa00 20fc00 20fe00 210000 210200 210400 210600 210800 210a00 210c00 210e00 211000 211200 211400 211600 211800 211a00 211c00 211e00 212000 212200 212400 212600 212800 212a00 212c00 212e00 213000 213200 213400 213600 213800 213a00 213c00 213e00 214000 214200 214400 214600 214800 214a00 214c00 214e00 215000 215200 215400 215600 215800 215a00 215c00 215e00 216000 216200 216400 216600 216800 216a00 216c00 216e00 217000 217200 217400 217600 217800 217a00 217c00 217e00 218000 218200 218400 218600 218800 218a00 218c00 218e00 219000 219200 219400 219600 219800 219a00 219c00 219e00 21a000 21a200 21a400 21a600 21a800 21aa00 21ac00 21ae00 21b000 21b200 21b400 21b600 21b800 21ba00 21bc00 21be00 21c000 21c200 21c400 21c600 21c800 21ca00 21cc00 21ce00 21d000 21d200 21d400 21d600 21d800 21da00 21dc00 21de00 21e000 21e200 21e400 21e600 21e800 21ea00 21ec00 21ee00 21f000 21f200 21f400 21f600 21f800 21fa00 21fc00 21fe00 220000 220200 220400 220600 220800 220a00 220c00 220e00 221000 221200 221400 221600 221800 221a00 221c00 221e00 222000 222200 222400 222600 222800 222a00 222c00 222e00 223000 223200 223400 223600 223800 223a00 223c00 223e00 224000 224200 224400 224600 224800 224a00 224c00 224e00 225000 225200 225400 225600 225800 225a00 225c00 225e00 226000 226200 226400 226600 226800 226a00 226c00 226e00 227000 227200 227400 227600 227800 227a00 227c00 227e00 228000 228200 228400 228600 228800 228a00 228c00 228e00 229000 229200 229400 229600 229800 229a00 229c00 229e00 22a000 22a200 22a400 22a600 22a800 22aa00 22ac00 22ae00 22b000 22b200 22b400 22b600 22b800 22ba00 22bc00 22be00 22c000 22c200 22c400 22c600 22c800 22ca00 22cc00 22ce00 22d000 22d200 22d400 22d600 22d800 22da00 22dc00 22de00 22e000 22e200 22e400 22e600 22e800 22ea00 22ec00 22ee00 22f000 22f200 22f400 22f600 22f800 22fa00 22fc00 22fe00 230000 230200 230400 230600 230800 230a00 230c00 230e00 231000 231200 231400 231600 231800 231a00 231c00 231e00 232000 232200 232400 232600 232800 232a00 232c00 232e00 233000 233200 233400 233600 233800 233a00 233c00 233e00 234000 234200 234400 234600 234800 234a00 234c00 234e00 235000 235200 235400 235600 235800 235a00 235c00 235e00 236000 236200 236400 236600 236800 236a00 236c00 236e00 237000 237200 237400 237600 237800 237a00 237c00 237e00 238000 238200 238400 238600 238800 238a00 238c00 238e00 239000 239200 239400 239600 239800 239a00 239c00 239e00 23a000 23a200 23a400 23a600 23a800 23aa00 23ac00 23ae00 23b000 23b200 23b400 23b600 23b800 23ba00 23bc00 23be00 23c000 23c200 23c400 23c600 23c800 23ca00 23cc00 23ce00 23d000 23d200 23d400 23d600 23d800 23da00 23dc00 23de00 23e000 23e200 23e400 23e600 23e800 23ea00 23ec00 23ee00 23f000 23f200 23f400 23f600 23f800 23fa00 23fc00 23fe00 240000 240200 240400 240600 240800 240a00 240c00 240e00 241000 241200 241400 241600 241800 241a00 241c00 241e00 242000 242200 242400 242600 242800 242a00 242c00 242e00 243000 243200 243400 243600 243800 243a00 243c00 243e00 244000 244200 244400 244600 244800 244a00 244c00 244e00 245000 245200 245400 245600 245800 245a00 245c00 245e00 246000 246200 246400 246600 246800 246a00 246c00 246e00 247000 247200 247400 247600 247800 247a00 247c00 247e00 248000 248200 248400 248600 248800 248a00 248c00 248e00 249000 249200 249400 249600 249800 249a00 249c00 249e00 24a000 24a200 24a400 24a600 24a800 24aa00 24ac00 24ae00 24b000 24b200 24b400 24b600 24b800 24ba00 24bc00 24be00 24c000 24c200 24c400 24c600 24c800 24ca00 24cc00 24ce00 24d000 24d200 24d400 24d600 24d800 24da00 24dc00 24de00 24e000 24e200 24e400 24e600 24e800 24ea00 24ec00 24ee00 24f000 24f200 24f400 24f600 24f800 24fa00 24fc00 24fe00 250000 250200 250400 250600 250800 250a00 250c00 250e00 251000 251200 251400 251600 251800 251a00 251c00 251e00 252000 252200 252400 252600 252800 252a00 252c00 252e00 253000 253200 253400 253600 253800 253a00 253c00 253e00 254000 254200 254400 254600 254800 254a00 254c00 254e00 255000 255200 255400 255600 255800 255a00 255c00 255e00 256000 256200 256400 256600 256800 256a00 256c00 256e00 257000 257200 257400 257600 257800 257a00 257c00 257e00 258000 258200 258400 258600 258800 258a00 258c00 258e00 259000 259200 259400 259600 259800 259a00 259c00 259e00 25a000 25a200 25a400 25a600 25a800 25aa00 25ac00 25ae00 25b000 25b200 25b400 25b600 25b800 25ba00 25bc00 25be00 25c000 25c200 25c400 25c600 25c800 25ca00 25cc00 25ce00 25d000 25d200 25d400 25d600 25d800 25da00 25dc00 25de00 25e000 25e200 25e400 25e600 25e800 25ea00 25ec00 25ee00 25f000 25f200 25f400 25f600 25f800 25fa00 25fc00 25fe00 260000 260200 260400 260600 260800 260a00 260c00 260e00 261000 261200 261400 261600 261800 261a00 261c00 261e00 262000 262200 262400 262600 262800 262a00 262c00 262e00 263000 263200 263400 263600 263800 263a00 263c00 263e00 264000 264200 264400 264600 264800 264a00 264c00 264e00 265000 265200 265400 265600 265800 265a00 265c00 265e00 266000 266200 266400 266600 266800 266a00 266c00 266e00 267000 267200 267400 267600 267800 267a00 267c00 267e00 268000 268200 268400 268600 268800 268a00 268c00 268e00 269000 269200 269400 269600 269800 269a00 269c00 269e00 26a000 26a200 26a400 26a600 26a800 26aa00 26ac00 26ae00 26b000 26b200 26b400 26b600 26b800 26ba00 26bc00 26be00 26c000 26c200 26c400 26c600 26c800 26ca00 26cc00 26ce00 26d000 26d200 26d400 26d600 26d800 26da00 26dc00 26de00 26e000 26e200 26e400 26e600 26e800 26ea00 26ec00 26ee00 26f000 26f200 26f400 26f600 26f800 26fa00 26fc00 26fe00 270000 270200 270400 270600 270800 270a00 270c00 270e00 271000 271200 271400 271600 271800 271a00 271c00 271e00 272000 272200 272400 272600 272800 272a00 272c00 272e00 273000 273200 273400 273600 273800 273a00 273c00 273e00 274000 274200 274400 274600 274800 274a00 274c00 274e00 275000 275200 275400 275600 275800 275a00 275c00 275e00 276000 276200 276400 276600 276800 276a00 276c00 276e00 277000 277200 277400 277600 277800 277a00 277c00 277e00 278000 278200 278400 278600 278800 278a00 278c00 278e00 279000 279200 279400 279600 279800 279a00 279c00 279e00 27a000 27a200 27a400 27a600 27a800 27aa00 27ac00 27ae00 27b000 27b200 27b400 27b600 27b800 27ba00 27bc00 27be00 27c000 27c200 27c400 27c600 27c800 27ca00 27cc00 27ce00 27d000 27d200 27d400 27d600 27d800 27da00 27dc00 27de00 27e000 27e200 27e400 27e600 27e800 27ea00 27ec00 27ee00 27f000 27f200 27f400 27f600 27f800 27fa00 27fc00 27fe00 280000 280200 280400 280600 280800 280a00 280c00 280e00 281000 281200 281400 281600 281800 281a00 281c00 281e00 282000 282200 282400 282600 282800 282a00 282c00 282e00 283000 283200 283400 283600 283800 283a00 283c00 283e00 284000 284200 284400 284600 284800 284a00 284c00 284e00 285000 285200 285400 285600 285800 285a00 285c00 285e00 286000 286200 286400 286600 286800 286a00 286c00 286e00 287000 287200 287400 287600 287800 287a00 287c00 287e00 288000 288200 288400 288600 288800 288a00 288c00 288e00 289000 289200 289400 289600 289800 289a00 289c00 289e00 28a000 28a200 28a400 28a600 28a800 28aa00 28ac00 28ae00 28b000 28b200 28b400 28b600 28b800 28ba00 28bc00 28be00 28c000 28c200 28c400 28c600 28c800 28ca00 28cc00 28ce00 28d000 28d200 28d400 28d600 28d800 28da00 28dc00 28de00 28e000 28e200 28e400 28e600 28e800 28ea00 28ec00 28ee00 28f000 28f200 28f400 28f600 28f800 28fa00 28fc00 28fe00 290000 290200 290400 290600 290800 290a00 290c00 290e00 291000 291200 291400 291600 291800 291a00 291c00 291e00 292000 292200 292400 292600 292800 292a00 292c00 292e00 293000 293200 293400 293600 293800 293a00 293c00 293e00 294000 294200 294400 294600 294800 294a00 294c00 294e00 295000 295200 295400 295600 295800 295a00 295c00 295e00 296000 296200 296400 296600 296800 296a00 296c00 296e00 297000 297200 297400 297600 297800 297a00 297c00 297e00 298000 298200 298400 298600 298800 298a00 298c00 298e00 299000 299200 299400 299600 299800 299a00 299c00 299e00 29a000 29a200 29a400 29a600 29a800 29aa00 29ac00 29ae00 29b000 29b200 29b400 29b600 29b800 29ba00 29bc00 29be00 29c000 29c200 29c400 29c600 29c800 29ca00 29cc00 29ce00 29d000 29d200 29d400 29d600 29d800 29da00 29dc00 29de00 29e000 29e200 29e400 29e600 29e800 29ea00 29ec00 29ee00 29f000 29f200 29f400 29f600 29f800 29fa00 29fc00 29fe00 2a0000 2a0200 2a0400 2a0600 2a0800 2a0a00 2a0c00 2a0e00 2a1000 2a1200 2a1400 2a1600 2a1800 2a1a00 2a1c00 2a1e00 2a2000 2a2200 2a2400 2a2600 2a2800 2a2a00 2a2c00 2a2e00 2a3000 2a3200 2a3400 2a3600 2a3800 2a3a00 2a3c00 2a3e00 2a4000 2a4200 2a4400 2a4600 2a4800 2a4a00 2a4c00 2a4e00 2a5000 2a5200 2a5400 2a5600 2a5800 2a5a00 2a5c00 2a5e00 2a6000 2a6200 2a6400 2a6600 2a6800 2a6a00 2a6c00 2a6e00 2a7000 2a7200 2a7400 2a7600 2a7800 2a7a00 2a7c00 2a7e00 2a8000 2a8200 2a8400 2a8600 2a8800 2a8a00 2a8c00 2a8e00 2a9000 2a9200 2a9400 2a9600 2a9800 2a9a00 2a9c00 2a9e00 2aa000 2aa200 2aa400 2aa600 2aa800 2aaa00 2aac00 2aae00 2ab000 2ab200 2ab400 2ab600 2ab800 2aba00 2abc00 2abe00 2ac000 2ac200 2ac400 2ac600 2ac800 2aca00 2acc00 2ace00 2ad000 2ad200 2ad400 2ad600 2ad800 2ada00 2adc00 2ade00 2ae000 2ae200 2ae400 2ae600 2ae800 2aea00 2aec00 2aee00 2af000 2af200 2af400 2af600 2af800 2afa00 2afc00 2afe00 2b0000 2b0200 2b0400 2b0600 2b0800 2b0a00 2b0c00 2b0e00 2b1000 2b1200 2b1400 2b1600 2b1800 2b1a00 2b1c00 2b1e00 2b2000 2b2200 2b2400 2b2600 2b2800 2b2a00 2b2c00 2b2e00 2b3000 2b3200 2b3400 2b3600 2b3800 2b3a00 2b3c00 2b3e00 2b4000 2b4200 2b4400 2b4600 2b4800 2b4a00 2b4c00 2b4e00 2b5000 2b5200 2b5400 2b5600 2b5800 2b5a00 2b5c00 2b5e00 2b6000 2b6200 2b6400 2b6600 2b6800 2b6a00 2b6c00 2b6e00 2b7000 2b7200 2b7400 2b7600 2b7800 2b7a00 2b7c00 2b7e00 2b8000 2b8200 2b8400 2b8600 2b8800 2b8a00 2b8c00 2b8e00 2b9000 2b9200 2b9400 2b9600 2b9800 2b9a00 2b9c00 2b9e00 2ba000 2ba200 2ba400 2ba600 2ba800 2baa00 2bac00 2bae00 2bb000 2bb200 2bb400 2bb600 2bb800 2bba00 2bbc00 2bbe00 2bc000 2bc200 2bc400 2bc600 2bc800 2bca00 2bcc00 2bce00 2bd000 2bd200 2bd400 2bd600 2bd800 2bda00 2bdc00 2bde00 2be000 2be200 2be400 2be600 2be800 2bea00 2bec00 2bee00 2bf000 2bf200 2bf400 2bf600 2bf800 2bfa00 2bfc00 2bfe00 2c0000 2c0200 2c0400 2c0600 2c0800 2c0a00 2c0c00 2c0e00 2c1000 2c1200 2c1400 2c1600 2c1800 2c1a00 2c1c00 2c1e00 2c2000 2c2200 2c2400 2c2600 2c2800 2c2a00 2c2c00 2c2e00 2c3000 2c3200 2c3400 2c3600 2c3800 2c3a00 2c3c00 2c3e00 2c4000 2c4200 2c4400 2c4600 2c4800 2c4a00 2c4c00 2c4e00 2c5000 2c5200 2c5400 2c5600 2c5800 2c5a00 2c5c00 2c5e00 2c6000 2c6200 2c6400 2c6600 2c6800 2c6a00 2c6c00 2c6e00 2c7000 2c7200 2c7400 2c7600 2c7800 2c7a00 2c7c00 2c7e00 2c8000 2c8200 2c8400 2c8600 2c8800 2c8a00 2c8c00 2c8e00 2c9000 2c9200 2c9400 2c9600 2c9800 2c9a00 2c9c00 2c9e00 2ca000 2ca200 2ca400 2ca600 2ca800 2caa00 2cac00 2cae00 2cb000 2cb200 2cb400 2cb600 2cb800 2cba00 2cbc00 2cbe00 2cc000 2cc200 2cc400 2cc600 2cc800 2cca00 2ccc00 2cce00 2cd000 2cd200 2cd400 2cd600 2cd800 2cda00 2cdc00 2cde00 2ce000 2ce200 2ce400 2ce600 2ce800 2cea00 2cec00 2cee00 2cf000 2cf200 2cf400 2cf600 2cf800 2cfa00 2cfc00 2cfe00 2d0000 2d0200 2d0400 2d0600 2d0800 2d0a00 2d0c00 2d0e00 2d1000 2d1200 2d1400 2d1600 2d1800 2d1a00 2d1c00 2d1e00 2d2000 2d2200 2d2400 2d2600 2d2800 2d2a00 2d2c00 2d2e00 2d3000 2d3200 2d3400 2d3600 2d3800 2d3a00 2d3c00 2d3e00 2d4000 2d4200 2d4400 2d4600 2d4800 2d4a00 2d4c00 2d4e00 2d5000 2d5200 2d5400 2d5600 2d5800 2d5a00 2d5c00 2d5e00 2d6000 2d6200 2d6400 2d6600 2d6800 2d6a00 2d6c00 2d6e00 2d7000 2d7200 2d7400 2d7600 2d7800 2d7a00 2d7c00 2d7e00 2d8000 2d8200 2d8400 2d8600 2d8800 2d8a00 2d8c00 2d8e00 2d9000 2d9200 2d9400 2d9600 2d9800 2d9a00 2d9c00 2d9e00 2da000 2da200 2da400 2da600 2da800 2daa00 2dac00 2dae00 2db000 2db200 2db400 2db600 2db800 2dba00 2dbc00 2dbe00 2dc000 2dc200 2dc400 2dc600 2dc800 2dca00 2dcc00 2dce00 2dd000 2dd200 2dd400 2dd600 2dd800 2dda00 2ddc00 2dde00 2de000 2de200 2de400 2de600 2de800 2dea00 2dec00 2dee00 2df000 2df200 2df400 2df600 2df800 2dfa00 2dfc00 2dfe00 2e0000 2e0200 2e0400 2e0600 2e0800 2e0a00 2e0c00 2e0e00 2e1000 2e1200 2e1400 2e1600 2e1800 2e1a00 2e1c00 2e1e00 2e2000 2e2200 2e2400 2e2600 2e2800 2e2a00 2e2c00 2e2e00 2e3000 2e3200 2e3400 2e3600 2e3800 2e3a00 2e3c00 2e3e00 2e4000 2e4200 2e4400 2e4600 2e4800 2e4a00 2e4c00 2e4e00 2e5000 2e5200 2e5400 2e5600 2e5800 2e5a00 2e5c00 2e5e00 2e6000 2e6200 2e6400 2e6600 2e6800 2e6a00 2e6c00 2e6e00 2e7000 2e7200 2e7400 2e7600 2e7800 2e7a00 2e7c00 2e7e00 2e8000 2e8200 2e8400 2e8600 2e8800 2e8a00 2e8c00 2e8e00 2e9000 2e9200 2e9400 2e9600 2e9800 2e9a00 2e9c00 2e9e00 2ea000 2ea200 2ea400 2ea600 2ea800 2eaa00 2eac00 2eae00 2eb000 2eb200 2eb400 2eb600 2eb800 2eba00 2ebc00 2ebe00 2ec000 2ec200 2ec400 2ec600 2ec800 2eca00 2ecc00 2ece00 2ed000 2ed200 2ed400 2ed600 2ed800 2eda00 2edc00 2ede00 2ee000 2ee200 2ee400 2ee600 2ee800 2eea00 2eec00 2eee00 2ef000 2ef200 2ef400 2ef600 2ef800 2efa00 2efc00 2efe00 2f0000 2f0200 2f0400 2f0600 2f0800 2f0a00 2f0c00 2f0e00 2f1000 2f1200 2f1400 2f1600 2f1800 2f1a00 2f1c00 2f1e00 2f2000 2f2200 2f2400 2f2600 2f2800 2f2a00 2f2c00 2f2e00 2f3000 2f3200 2f3400 2f3600 2f3800 2f3a00 2f3c00 2f3e00 2f4000 2f4200 2f4400 2f4600 2f4800 2f4a00 2f4c00 2f4e00 2f5000 2f5200 2f5400 2f5600 2f5800 2f5a00 2f5c00 2f5e00 2f6000 2f6200 2f6400 2f6600 2f6800 2f6a00 2f6c00 2f6e00 2f7000 2f7200 2f7400 2f7600 2f7800 2f7a00 2f7c00 2f7e00 2f8000 2f8200 2f8400 2f8600 2f8800 2f8a00 2f8c00 2f8e00 2f9000 2f9200 2f9400 2f9600 2f9800 2f9a00 2f9c00 2f9e00 2fa000 2fa200 2fa400 2fa600 2fa800 2faa00 2fac00 2fae00 2fb000 2fb200 2fb400 2fb600 2fb800 2fba00 2fbc00 2fbe00 2fc000 2fc200 2fc400 2fc600 2fc800 2fca00 2fcc00 2fce00 2fd000 2fd200 2fd400 2fd600 2fd800 2fda00 2fdc00 2fde00 2fe000 2fe200 2fe400 2fe600 2fe800 2fea00 2fec00 2fee00 2ff000 2ff200 2ff400 2ff600 2ff800 2ffa00 2ffc00 2ffe00 300000 300200 300400 300600 300800 300a00 300c00 300e00 301000 301200 301400 301600 301800 301a00 301c00 301e00 302000 302200 302400 302600 302800 302a00 302c00 302e00 303000 303200 303400 303600 303800 303a00 303c00 303e00 304000 304200 304400 304600 304800 304a00 304c00 304e00 305000 305200 305400 305600 305800 305a00 305c00 305e00 306000 306200 306400 306600 306800 306a00 306c00 306e00 307000 307200 307400 307600 307800 307a00 307c00 307e00 308000 308200 308400 308600 308800 308a00 308c00 308e00 309000 309200 309400 309600 309800 309a00 309c00 309e00 30a000 30a200 30a400 30a600 30a800 30aa00 30ac00 30ae00 30b000 30b200 30b400 30b600 30b800 30ba00 30bc00 30be00 30c000 30c200 30c400 30c600 30c800 30ca00 30cc00 30ce00 30d000 30d200 30d400 30d600 30d800 30da00 30dc00 30de00 30e000 30e200 30e400 30e600 30e800 30ea00 30ec00 30ee00 30f000 30f200 30f400 30f600 30f800 30fa00 30fc00 30fe00 310000 310200 310400 310600 310800 310a00 310c00 310e00 311000 311200 311400 311600 311800 311a00 311c00 311e00 312000 312200 312400 312600 312800 312a00 312c00 312e00 313000 313200 313400 313600 313800 313a00 313c00 313e00 314000 314200 314400 314600 314800 314a00 314c00 314e00 315000 315200 315400 315600 315800 315a00 315c00 315e00 316000 316200 316400 316600 316800 316a00 316c00 316e00 317000 317200 317400 317600 317800 317a00 317c00 317e00 318000 318200 318400 318600 318800 318a00 318c00 318e00 319000 319200 319400 319600 319800 319a00 319c00 319e00 31a000 31a200 31a400 31a600 31a800 31aa00 31ac00 31ae00 31b000 31b200 31b400 31b600 31b800 31ba00 31bc00 31be00 31c000 31c200 31c400 31c600 31c800 31ca00 31cc00 31ce00 31d000 31d200 31d400 31d600 31d800 31da00 31dc00 31de00 31e000 31e200 31e400 31e600 31e800 31ea00 31ec00 31ee00 31f000 31f200 31f400 31f600 31f800 31fa00 31fc00 31fe00 320000 320200 320400 320600 320800 320a00 320c00 320e00 321000 321200 321400 321600 321800 321a00 321c00 321e00 322000 322200 322400 322600 322800 322a00 322c00 322e00 323000 323200 323400 323600 323800 323a00 323c00 323e00 324000 324200 324400 324600 324800 324a00 324c00 324e00 325000 325200 325400 325600 325800 325a00 325c00 325e00 326000 326200 326400 326600 326800 326a00 326c00 326e00 327000 327200 327400 327600 327800 327a00 327c00 327e00 328000 328200 328400 328600 328800 328a00 328c00 328e00 329000 329200 329400 329600 329800 329a00 329c00 329e00 32a000 32a200 32a400 32a600 32a800 32aa00 32ac00 32ae00 32b000 32b200 32b400 32b600 32b800 32ba00 32bc00 32be00 32c000 32c200 32c400 32c600 32c800 32ca00 32cc00 32ce00 32d000 32d200 32d400 32d600 32d800 32da00 32dc00 32de00 32e000 32e200 32e400 32e600 32e800 32ea00 32ec00 32ee00 32f000 32f200 32f400 32f600 32f800 32fa00 32fc00 32fe00 330000 330200 330400 330600 330800 330a00 330c00 330e00 331000 331200 331400 331600 331800 331a00 331c00 331e00 332000 332200 332400 332600 332800 332a00 332c00 332e00 333000 333200 333400 333600 333800 333a00 333c00 333e00 334000 334200 334400 334600 334800 334a00 334c00 334e00 335000 335200 335400 335600 335800 335a00 335c00 335e00 336000 336200 336400 336600 336800 336a00 336c00 336e00 337000 337200 337400 337600 337800 337a00 337c00 337e00 338000 338200 338400 338600 338800 338a00 338c00 338e00 339000 339200 339400 339600 339800 339a00 339c00 339e00 33a000 33a200 33a400 33a600 33a800 33aa00 33ac00 33ae00 33b000 33b200 33b400 33b600 33b800 33ba00 33bc00 33be00 33c000 33c200 33c400 33c600 33c800 33ca00 33cc00 33ce00 33d000 33d200 33d400 33d600 33d800 33da00 33dc00 33de00 33e000 33e200 33e400 33e600 33e800 33ea00 33ec00 33ee00 33f000 33f200 33f400 33f600 33f800 33fa00 33fc00 33fe00 340000 340200 340400 340600 340800 340a00 340c00 340e00 341000 341200 341400 341600 341800 341a00 341c00 341e00 342000 342200 342400 342600 342800 342a00 342c00 342e00 343000 343200 343400 343600 343800 343a00 343c00 343e00 344000 344200 344400 344600 344800 344a00 344c00 344e00 345000 345200 345400 345600 345800 345a00 345c00 345e00 346000 346200 346400 346600 346800 346a00 346c00 346e00 347000 347200 347400 347600 347800 347a00 347c00 347e00 348000 348200 348400 348600 348800 348a00 348c00 348e00 349000 349200 349400 349600 349800 349a00 349c00 349e00 34a000 34a200 34a400 34a600 34a800 34aa00 34ac00 34ae00 34b000 34b200 34b400 34b600 34b800 34ba00 34bc00 34be00 34c000 34c200 34c400 34c600 34c800 34ca00 34cc00 34ce00 34d000 34d200 34d400 34d600 34d800 34da00 34dc00 34de00 34e000 34e200 34e400 34e600 34e800 34ea00 34ec00 34ee00 34f000 34f200 34f400 34f600 34f800 34fa00 34fc00 34fe00 350000 350200 350400 350600 350800 350a00 350c00 350e00 351000 351200 351400 351600 351800 351a00 351c00 351e00 352000 352200 352400 352600 352800 352a00 352c00 352e00 353000 353200 353400 353600 353800 353a00 353c00 353e00 354000 354200 354400 354600 354800 354a00 354c00 354e00 355000 355200 355400 355600 355800 355a00 355c00 355e00 356000 356200 356400 356600 356800 356a00 356c00 356e00 357000 357200 357400 357600 357800 357a00 357c00 357e00 358000 358200 358400 358600 358800 358a00 358c00 358e00 359000 359200 359400 359600 359800 359a00 359c00 359e00 35a000 35a200 35a400 35a600 35a800 35aa00 35ac00 35ae00 35b000 35b200 35b400 35b600 35b800 35ba00 35bc00 35be00 35c000 35c200 35c400 35c600 35c800 35ca00 35cc00 35ce00 35d000 35d200 35d400 35d600 35d800 35da00 35dc00 35de00 35e000 35e200 35e400 35e600 35e800 35ea00 35ec00 35ee00 35f000 35f200 35f400 35f600 35f800 35fa00 35fc00 35fe00 360000 360200 360400 360600 360800 360a00 360c00 360e00 361000 361200 361400 361600 361800 361a00 361c00 361e00 362000 362200 362400 362600 362800 362a00 362c00 362e00 363000 363200 363400 363600 363800 363a00 363c00 363e00 364000 364200 364400 364600 364800 364a00 364c00 364e00 365000 365200 365400 365600 365800 365a00 365c00 365e00 366000 366200 366400 366600 366800 366a00 366c00 366e00 367000 367200 367400 367600 367800 367a00 367c00 367e00 368000 368200 368400 368600 368800 368a00 368c00 368e00 369000 369200 369400 369600 369800 369a00 369c00 369e00 36a000 36a200 36a400 36a600 36a800 36aa00 36ac00 36ae00 36b000 36b200 36b400 36b600 36b800 36ba00 36bc00 36be00 36c000 36c200 36c400 36c600 36c800 36ca00 36cc00 36ce00 36d000 36d200 36d400 36d600 36d800 36da00 36dc00 36de00 36e000 36e200 36e400 36e600 36e800 36ea00 36ec00 36ee00 36f000 36f200 36f400 36f600 36f800 36fa00 36fc00 36fe00 370000 370200 370400 370600 370800 370a00 370c00 370e00 371000 371200 371400 371600 371800 371a00 371c00 371e00 372000 372200 372400 372600 372800 372a00 372c00 372e00 373000 373200 373400 373600 373800 373a00 373c00 373e00 374000 374200 374400 374600 374800 374a00 374c00 374e00 375000 375200 375400 375600 375800 375a00 375c00 375e00 376000 376200 376400 376600 376800 376a00 376c00 376e00 377000 377200 377400 377600 377800 377a00 377c00 377e00 378000 378200 378400 378600 378800 378a00 378c00 378e00 379000 379200 379400 379600 379800 379a00 379c00 379e00 37a000 37a200 37a400 37a600 37a800 37aa00 37ac00 37ae00 37b000 37b200 37b400 37b600 37b800 37ba00 37bc00 37be00 37c000 37c200 37c400 37c600 37c800 37ca00 37cc00 37ce00 37d000 37d200 37d400 37d600 37d800 37da00 37dc00 37de00 37e000 37e200 37e400 37e600 37e800 37ea00 37ec00 37ee00 37f000 37f200 37f400 37f600 37f800 37fa00 37fc00 37fe00 380000 380200 380400 380600 380800 380a00 380c00 380e00 381000 381200 381400 381600 381800 381a00 381c00 381e00 382000 382200 382400 382600 382800 382a00 382c00 382e00 383000 383200 383400 383600 383800 383a00 383c00 383e00 384000 384200 384400 384600 384800 384a00 384c00 384e00 385000 385200 385400 385600 385800 385a00 385c00 385e00 386000 386200 386400 386600 386800 386a00 386c00 386e00 387000 387200 387400 387600 387800 387a00 387c00 387e00 388000 388200 388400 388600 388800 388a00 388c00 388e00 389000 389200 389400 389600 389800 389a00 389c00 389e00 38a000 38a200 38a400 38a600 38a800 38aa00 38ac00 38ae00 38b000 38b200 38b400 38b600 38b800 38ba00 38bc00 38be00 38c000 38c200 38c400 38c600 38c800 38ca00 38cc00 38ce00 38d000 38d200 38d400 38d600 38d800 38da00 38dc00 38de00 38e000 38e200 38e400 38e600 38e800 38ea00 38ec00 38ee00 38f000 38f200 38f400 38f600 38f800 38fa00 38fc00 38fe00 390000 390200 390400 390600 390800 390a00 390c00 390e00 391000 391200 391400 391600 391800 391a00 391c00 391e00 392000 392200 392400 392600 392800 392a00 392c00 392e00 393000 393200 393400 393600 393800 393a00 393c00 393e00 394000 394200 394400 394600 394800 394a00 394c00 394e00 395000 395200 395400 395600 395800 395a00 395c00 395e00 396000 396200 396400 396600 396800 396a00 396c00 396e00 397000 397200 397400 397600 397800 397a00 397c00 397e00 398000 398200 398400 398600 398800 398a00 398c00 398e00 399000 399200 399400 399600 399800 399a00 399c00 399e00 39a000 39a200 39a400 39a600 39a800 39aa00 39ac00 39ae00 39b000 39b200 39b400 39b600 39b800 39ba00 39bc00 39be00 39c000 39c200 39c400 39c600 39c800 39ca00 39cc00 39ce00 39d000 Remapping the kernel... done. Booting Linux...   [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@   [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ [1@  [1@  [1@ PROMLIB: Sun IEEE Boot Prom 3.2.30 2002/10/25 14:03 Linux version 2.6.4-mm1 (wli@analyticity) (gcc version 3.3.3 (Debian)) #3 SMP Fri Mar 12 00:32:32 PST 2004 ARCH: SUN4U Ethernet address: 08:00:20:89:ed:b7 On node 0 totalpages: 490167 DMA zone: 490167 pages, LIFO batch:8 Normal zone: 0 pages, LIFO batch:1 HighMem zone: 0 pages, LIFO batch:1 CENTRAL: Detected 4 slot Enterprise system. cfreg[a8] cver[fc] FHC(board 1): Version[1] PartID[fa0] Manuf[3e] (CENTRAL) FHC(board 3): Version[1] PartID[fa0] Manuf[3e] (JTAG Master) FHC(board 5): Version[1] PartID[fa0] Manuf[3e] FHC(board 7): Version[1] PartID[fa0] Manuf[3e] FHC(board 1): Version[1] PartID[fa0] Manuf[3e] Built 1 zonelists Kernel command line: root=/dev/nfs nfsroot=/mnt/f/e3k/debian ip=dhcp debug initcall_debug profile=1 kernel profiling enabled PID hash table entries: 4096 (order 12: 65536 bytes) Console: colour dummy device 80x25 Memory: 3879488k available (2784k kernel code, 744k data, 136k init) [fffff80000000000,00000000efd18000] Calibrating delay loop... 671.74 BogoMIPS  Dentry cache hash table entries: 524288 (order: 9, 4194304 bytes)  Inode-cache hash table entries: 262144 (order: 8, 2097152 bytes)  Mount-cache hash table entries: 512 (order: 0, 8192 bytes)  POSIX conformance testing by UNIFIX  Calibrating delay loop... 670.10 BogoMIPS  CPU 7: synchronized TICK with master CPU (last diff -11 cycles,maxerr 677 cycles) Calibrating delay loop... 670.10 BogoMIPS  CPU 10: synchronized TICK with master CPU (last diff -16 cycles,maxerr 686 cycles) Calibrating delay loop... 670.10 BogoMIPS  CPU 11: synchronized TICK with master CPU (last diff -12 cycles,maxerr 682 cycles) Calibrating delay loop... 670.10 BogoMIPS  CPU 14: synchronized TICK with master CPU (last diff -15 cycles,maxerr 686 cycles) Calibrating delay loop... 670.10 BogoMIPS  CPU 15: synchronized TICK with master CPU (last diff -16 cycles,maxerr 686 cycles) Brought up 6 CPUs  Total of 6 processors activated (4022.27 BogoMIPS).  SMP: Calibrating ecache flush... Using heuristic of 1196154 cycles, 1 ticks.  Calling initcall 0x00000000007903e0: netlink_proto_init+0x0/0x60()  NET: Registered protocol family 16  Calling initcall 0x0000000000788440: tty_class_init+0x0/0x40()  Calling initcall 0x000000000077edc0: topology_init+0x0/0xa0()  Calling initcall 0x0000000000784de0: init_bio+0x0/0xc0()  Calling initcall 0x0000000000788940: misc_init+0x0/0xc0()  Calling initcall 0x000000000078a3e0: device_init+0x0/0x40()  Calling initcall 0x000000000078a420: deadline_slab_setup+0x0/0x60()  Calling initcall 0x000000000078a480: cfq_slab_setup+0x0/0xc0()  Calling initcall 0x000000000078cf00: init_scsi+0x0/0x140()  SCSI subsystem initialized  Calling initcall 0x000000000078ef00: sbus_init+0x0/0x340()  SYSIO: UPA portID 2, at 000001c400000000  sbus0: Clock 25.0 MHz  SYSIO: UPA portID 3, at 000001c600000000  sbus1: Clock 25.0 MHz  dma0: HME DVMA gate array  Calling initcall 0x000000000078f800: input_init+0x0/0xc0()  Calling initcall 0x0000000000790140: net_dev_init+0x0/0x1c0()  Calling initcall 0x0000000000788180: chr_dev_init+0x0/0xc0()  Calling initcall 0x0000000000780560: chmc_init+0x0/0x60()  Calling initcall 0x0000000000780f00: init_elf32_binfmt+0x0/0x20()  Calling initcall 0x0000000000782660: abi_register_sysctl+0x0/0x40()  Calling initcall 0x0000000000782be0: ioresources_init+0x0/0x60()  Calling initcall 0x0000000000782da0: uid_cache_init+0x0/0xc0()  Calling initcall 0x0000000000783100: init_posix_timers+0x0/0xc0()  Calling initcall 0x00000000007831c0: init+0x0/0x80()  Calling initcall 0x0000000000783240: proc_dma_init+0x0/0x40()  Calling initcall 0x000000000045e5e0: percpu_modinit+0x0/0xa0()  Calling initcall 0x0000000000783280: kallsyms_init+0x0/0x40()  Calling initcall 0x00000000007832c0: ikconfig_init+0x0/0x60()  ikconfig 0.7 with /proc/config*  Calling initcall 0x0000000000784560: init_per_zone_pages_min+0x0/0x60()  Calling initcall 0x0000000000784680: pdflush_init+0x0/0x20()  Calling initcall 0x0000000000784940: cpucache_init+0x0/0x80()  Calling initcall 0x0000000000784a00: kswapd_init+0x0/0x60()  Calling initcall 0x0000000000784ac0: init_tmpfs+0x0/0xe0()  Calling initcall 0x0000000000784ba0: procswaps_init+0x0/0x40()  Calling initcall 0x0000000000784fc0: init_pipe_fs+0x0/0x60()  Calling initcall 0x0000000000785020: fasync_init+0x0/0x60()  Calling initcall 0x0000000000785080: filelock_init+0x0/0x60()  Calling initcall 0x0000000000785540: dnotify_init+0x0/0x60()  Calling initcall 0x0000000000785820: aio_setup+0x0/0xa0()  Calling initcall 0x00000000007858c0: eventpoll_init+0x0/0x120()  Calling initcall 0x00000000007859e0: init_sys32_ioctl+0x0/0x80()  Calling initcall 0x0000000000785a60: init_misc_binfmt+0x0/0x60()  Calling initcall 0x0000000000785ac0: init_script_binfmt+0x0/0x20()  Calling initcall 0x0000000000785ae0: init_elf_binfmt+0x0/0x20()  Calling initcall 0x0000000000785b00: init_mbcache+0x0/0x40()  Calling initcall 0x0000000000786060: init_devpts_fs+0x0/0x80()  Calling initcall 0x0000000000786100: init_ext3_fs+0x0/0x60()  Calling initcall 0x0000000000786320: journal_init+0x0/0x40()  Calling initcall 0x0000000000786360: init_ext2_fs+0x0/0x60()  Calling initcall 0x0000000000786480: init_ramfs_fs+0x0/0x20()  Calling initcall 0x00000000007864c0: init_minix_fs+0x0/0x60()  Calling initcall 0x0000000000786520: init_iso9660_fs+0x0/0x60()  Calling initcall 0x0000000000786580: init_nfs_fs+0x0/0xc0()  Calling initcall 0x0000000000786d60: init_nlm+0x0/0x40()  Calling initcall 0x0000000000786da0: init_udf_fs+0x0/0x60()  udf: registering filesystem  Calling initcall 0x00000000007872a0: init_openprom_fs+0x0/0xa0()  Calling initcall 0x00000000007873e0: init_xfs_fs+0x0/0xa0()  SGI XFS with large block/inode numbers, no debug enabled  Calling initcall 0x0000000000787480: ipc_init+0x0/0x40()  Calling initcall 0x00000000007876c0: init_mqueue_fs+0x0/0x100()  Calling initcall 0x00000000007877c0: init_crypto+0x0/0x40()  Initializing Cryptographic API  Calling initcall 0x0000000000787840: init+0x0/0x20()  Calling initcall 0x0000000000787860: init+0x0/0x20()  Calling initcall 0x0000000000787880: init+0x0/0x60()  Calling initcall 0x00000000007878e0: init+0x0/0x20()  Calling initcall 0x00000000007882e0: rand_initialize+0x0/0x100()  Calling initcall 0x0000000000788480: tty_init+0x0/0x260()  Console: switching to mono PROM 80x34  Calling initcall 0x00000000007886e0: pty_init+0x0/0x260()  Calling initcall 0x0000000000789260: suncore_init+0x0/0x60()  Calling initcall 0x0000000000789fc0: sunzilog_init+0x0/0x40()  SunZilog: 2 chips.  zs2 at 0x000001fff8904004 (irq = 12,b9) is a SunZilog  zs3 at 0x000001fff8904000 (irq = 12,b9) is a SunZilog  ttyS0 at MMIO 0x0 (irq = 7996832) is a SunZilog  ttyS1 at MMIO 0x0 (irq = 7996832) is a SunZilog  Console: ttyS0 (SunZilog zs0)  Calling initcall 0x000000000078a200: firmware_class_init+0x0/0x80()  Calling initcall 0x00000000005e72c0: elevator_global_init+0x0/0x20()  Calling initcall 0x000000000078a540: loop_init+0x0/0x340()  loop: loaded (max 8 devices)  Calling initcall 0x000000000078a8c0: nbd_init+0x0/0x260()  Using deadline io scheduler  nbd: registered device at major 43  Calling initcall 0x000000000078b500: happy_meal_probe+0x0/0x40()  sunhme.c:v2.02 24/Aug/2003 David S. Miller (davem@redhat.com)  eth0: HAPPY MEAL (SBUS) 10/100baseT Ethernet 08:00:20:89:ed:b7  Calling initcall 0x000000000078baa0: sparc_lance_probe+0x0/0x160()  Calling initcall 0x000000000078c5a0: qec_probe+0x0/0xc0()  Calling initcall 0x000000000078cc00: bigmac_probe+0x0/0xc0()  Calling initcall 0x000000000078ce40: net_olddevs_init+0x0/0x60()  Calling initcall 0x000000000078e240: init_this_scsi_driver+0x0/0xe0()  esp0: IRQ 7,db SCSI ID 7 Clk 40MHz CCYC=25000 CCF=8 TOut 167 NCR53C9XF(espfast)  ESP: Total of 1 ESP hosts found, 1 actually in use.  scsi0 : Sparc ESP366-HME  Vendor: SEAGATE Model: SX118202LS Rev: B808  Type: Direct-Access ANSI SCSI revision: 02  Vendor: SEAGATE Model: SX118202LS Rev: B808  Type: Direct-Access ANSI SCSI revision: 02  Vendor: SEAGATE Model: SX118202LS Rev: B808  Type: Direct-Access ANSI SCSI revision: 02  Vendor: SEAGATE Model: SX118202LS Rev: B808  Type: Direct-Access ANSI SCSI revision: 02  Vendor: TOSHIBA Model: XM5701TASUN12XCD Rev: 2395  Type: CD-ROM ANSI SCSI revision: 02  Vendor: SEAGATE Model: SX118202LS Rev: B807  Type: Direct-Access ANSI SCSI revision: 02  Vendor: SEAGATE Model: SX118202LS Rev: B807  Type: Direct-Access ANSI SCSI revision: 02  Vendor: SEAGATE Model: SX118202LS Rev: B807  Type: Direct-Access ANSI SCSI revision: 02  Vendor: SEAGATE Model: SX118202LS Rev: B807  Type: Direct-Access ANSI SCSI revision: 02  Vendor: SEAGATE Model: SX118202LS Rev: B807  Type: Direct-Access ANSI SCSI revision: 02  Vendor: SEAGATE Model: SX118202LS Rev: B808  Type: Direct-Access ANSI SCSI revision: 02  Calling initcall 0x000000000078e4c0: init_st+0x0/0x100()  st: Version 20040226, fixed bufsize 32768, s/g segs 256  Calling initcall 0x000000000078e5c0: init_sd+0x0/0x60()  esp0: target 0 [period 100ns offset 15 20.00MHz FAST-WIDE SCSI-II]  SCSI device sda: 35566480 512-byte hdwr sectors (18210 MB)  SCSI device sda: drive cache: write through  sda: unknown partition table  Attached scsi disk sda at scsi0, channel 0, id 0, lun 0  esp0: target 1 [period 100ns offset 15 20.00MHz FAST-WIDE SCSI-II]  SCSI device sdb: 35566480 512-byte hdwr sectors (18210 MB)  SCSI device sdb: drive cache: write through  sdb: unknown partition table  Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0  esp0: target 2 [period 100ns offset 15 20.00MHz FAST-WIDE SCSI-II]  SCSI device sdc: 35566480 512-byte hdwr sectors (18210 MB)  SCSI device sdc: drive cache: write through  sdc: unknown partition table  Attached scsi disk sdc at scsi0, channel 0, id 2, lun 0  esp0: target 3 [period 100ns offset 15 20.00MHz FAST-WIDE SCSI-II]  SCSI device sdd: 35566480 512-byte hdwr sectors (18210 MB)  SCSI device sdd: drive cache: write through  sdd: unknown partition table  Attached scsi disk sdd at scsi0, channel 0, id 3, lun 0  esp0: target 10 [period 100ns offset 15 20.00MHz FAST-WIDE SCSI-II]  SCSI device sde: 35566480 512-byte hdwr sectors (18210 MB)  SCSI device sde: drive cache: write through  sde: unknown partition table  Attached scsi disk sde at scsi0, channel 0, id 10, lun 0  esp0: target 11 [period 100ns offset 15 20.00MHz FAST-WIDE SCSI-II]  SCSI device sdf: 35566480 512-byte hdwr sectors (18210 MB)  SCSI device sdf: drive cache: write through  sdf: unknown partition table  Attached scsi disk sdf at scsi0, channel 0, id 11, lun 0  esp0: target 12 [period 100ns offset 15 20.00MHz FAST-WIDE SCSI-II]  SCSI device sdg: 35566480 512-byte hdwr sectors (18210 MB)  SCSI device sdg: drive cache: write through  sdg: unknown partition table  Attached scsi disk sdg at scsi0, channel 0, id 12, lun 0  esp0: target 13 [period 100ns offset 15 20.00MHz FAST-WIDE SCSI-II]  SCSI device sdh: 35566480 512-byte hdwr sectors (18210 MB)  SCSI device sdh: drive cache: write through  sdh: unknown partition table  Attached scsi disk sdh at scsi0, channel 0, id 13, lun 0  esp0: target 14 [period 100ns offset 15 20.00MHz FAST-WIDE SCSI-II]  SCSI device sdi: 35566480 512-byte hdwr sectors (18210 MB)  SCSI device sdi: drive cache: write through  sdi: unknown partition table  Attached scsi disk sdi at scsi0, channel 0, id 14, lun 0  esp0: target 15 [period 100ns offset 15 20.00MHz FAST-WIDE SCSI-II]  SCSI device sdj: 35566480 512-byte hdwr sectors (18210 MB)  SCSI device sdj: drive cache: write through  sdj: unknown partition table  Attached scsi disk sdj at scsi0, channel 0, id 15, lun 0  Calling initcall 0x000000000078e620: init_sr+0x0/0x40()  esp0: target 6 asynchronous  sr0: scsi-1 drive  Uniform CD-ROM driver Revision: 3.20  Attached scsi CD-ROM sr0 at scsi0, channel 0, id 6, lun 0  Calling initcall 0x000000000078e660: init_sg+0x0/0xe0()  Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0  Attached scsi generic sg1 at scsi0, channel 0, id 1, lun 0, type 0  Attached scsi generic sg2 at scsi0, channel 0, id 2, lun 0, type 0  Attached scsi generic sg3 at scsi0, channel 0, id 3, lun 0, type 0  Attached scsi generic sg4 at scsi0, channel 0, id 6, lun 0, type 5  Attached scsi generic sg5 at scsi0, channel 0, id 10, lun 0, type 0  Attached scsi generic sg6 at scsi0, channel 0, id 11, lun 0, type 0  Attached scsi generic sg7 at scsi0, channel 0, id 12, lun 0, type 0  Attached scsi generic sg8 at scsi0, channel 0, id 13, lun 0, type 0  Attached scsi generic sg9 at scsi0, channel 0, id 14, lun 0, type 0  Attached scsi generic sg10 at scsi0, channel 0, id 15, lun 0, type 0  Calling initcall 0x000000000078e740: cdrom_init+0x0/0x20()  Calling initcall 0x000000000078f4e0: flash_init+0x0/0x140()  Calling initcall 0x000000000078f620: openprom_init+0x0/0xa0()  Calling initcall 0x000000000078f6c0: rtc_sun_init+0x0/0x60()  Calling initcall 0x000000000078f8c0: atkbd_init+0x0/0x20()  Calling initcall 0x000000000078f8e0: psmouse_init+0x0/0xc0()  Calling initcall 0x000000000078f9a0: serio_init+0x0/0x60()  Calling initcall 0x000000000078fa00: serport_init+0x0/0x40()  Calling initcall 0x000000000078fb00: dm_init+0x0/0xa0()  device-mapper: 4.1.0-ioctl (2003-12-10) initialised: dm@uk.sistina.com  Calling initcall 0x000000000078fe40: flow_cache_init+0x0/0x1e0()  Calling initcall 0x0000000000790440: init_netlink+0x0/0x120()  Calling initcall 0x0000000000791480: inet_init+0x0/0x240()  NET: Registered protocol family 2  IP: routing cache hash table of 16384 buckets, 384Kbytes  TCP: Hash tables configured (established 32768 bind 43690)  Calling initcall 0x0000000000791a20: ah4_init+0x0/0x80()  Calling initcall 0x0000000000791aa0: esp4_init+0x0/0x80()  Calling initcall 0x0000000000791b20: ipcomp4_init+0x0/0x160()  Calling initcall 0x0000000000793da0: ipip_init+0x0/0x80()  Calling initcall 0x0000000000793fe0: af_unix_init+0x0/0xa0()  NET: Registered protocol family 1  Calling initcall 0x0000000000794080: packet_init+0x0/0x60()  NET: Registered protocol family 17  Calling initcall 0x00000000007940e0: ipsec_pfkey_init+0x0/0x60()  NET: Registered protocol family 15  Calling initcall 0x0000000000794140: init_sunrpc+0x0/0x80()  Calling initcall 0x00000000007941c0: init_rpcsec_gss+0x0/0x60()  Calling initcall 0x0000000000794220: init_kerberos_module+0x0/0xc0()  Calling initcall 0x00000000007936e0: ip_auto_config+0x0/0x320()  Sending DHCP requests .<6>eth0: Link is up using internal transceiver at 100Mb/s, Full Duplex.  ., OK  IP-Config: Got DHCP answer from 192.168.1.1, my address is 192.168.1.16  IP-Config: Complete:  device=eth0, addr=192.168.1.16, mask=255.255.255.0, gw=192.168.1.1,  host=analyticity, domain=holomorphy.com, nis-domain=(none),  bootserver=192.168.1.1, rootserver=192.168.1.1, rootpath=/mnt/f/e3k/debian  Looking up port of RPC 100003/2 on 192.168.1.1  Looking up port of RPC 100005/1 on 192.168.1.1  VFS: Mounted root (nfs filesystem) readonly.  INIT: Activating swap. System time was Fri Mar 12 08:43:41 UTC 2004. Setting the System Clock using the Hardware Clock as reference... System Clock set. System local time is now Fri Mar 12 08:43:43 UTC 2004. Not running depmod because /lib/modules/2.6.4-mm1/ is not writeable. Loading modules... All modules loaded. FATAL: Could not load /lib/modules/2.6.4-mm1/modules.dep: No such file or directory Checking all file systems... fsck 1.35-WIP (31-Jan-2004) Setting kernel variables.. Mounting local filesystems... none on /tmp type tmpfs (rw) Cleaning /tmp /var/run /var/lock. Cleaning: /etc/network/ifstate. Setting up IP spoofing protection: rp_filter. Configuring network interfaces: done. Starting portmap daemon: portmap. Starting portmapper...Mounting remote filesystemsnfs warning: mount version older than kernel  ... Setting the System Clock using the Hardware Clock as reference... System Clock set. Local time: Fri Mar 12 00:43:47 PST 2004 Initializing random number generator...done. Recovering nvi editor sessions... done. Setting up X server socket directory /tmp/.X11-unix...done. Set INIT: Entering runlevel: 2 Starting system log daemon: syslogd. Starting kernel log daemon: klogd. Starting Courier authdaemon: done. Starting Courier mail server: done. Starting Courier mail filter: done. Starting Courier SMTP server:FATAL: Could not load /lib/modules/2.6.4-mm1/modules.dep: No such file or directory done. Starting internet superserver: inetd. Starting OpenBSD Secure Shell server: sshd. FATAL: Could not load /lib/modules/2.6.4-mm1/modules.dep: No such file or directory Starting the system activity data collector: sadc. Starting NFS common utilities: statd lockdlockdsvc: Function not implemented . Debian GNU/Linux testing/unstable analyticity ttyS0 analyticity login: root Password: Last login: Fri Mar 12 00:37:45 2004 on ttyS0 Linux analyticity 2.6.4-mm1 #3 SMP Fri Mar 12 00:32:32 PST 2004 sparc64 GNU/Linux The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. # /dme setup # dmsetup create dm0 /work/wli/stripes 2>&1 | tee -a dm.log.13 # dmsetup create dm0 /work/wli/stripes 2>&1 | tee -a dm.log.14 # /mount # mount /dev/mapper/dm0 /mnt/dm0 -t xfs -o noatime # XFS mounting filesystem dm-0  Starting XFS recovery on filesystem: dm-0 (dev: dm-0)  Unable to handle kernel NULL pointer dereference  tsk->{mm,active_mm}->context = 0000000000000581  tsk->{mm,active_mm}->pgd = fffff800ed3ec000  \|/ ____ \|/  "@'/ .. \`@"  /_| \__/ |_\  \__U_/  mount(272): Oops [#1]  TSTATE: 0000000011009601 TPC: 00000000005414d0 TNPC: 00000000005414d4 Y: 00000000 Not tainted  TPC:  g0: 0000000000000000 g1: 0000000000000000 g2: 0000000000000000 g3: 0000000000000000 g4: fffff800edc88140 g5: 0000000000000000 g6: fffff800ece10000 g7: fffff80002cb6810 o0: ffffffffffffffff o1: ffff001da00f6300 o2: 0000000000000001 o3: 0000000000000080 o4: 0000000000000080 o5: 0000000000200200 sp: fffff800ece12611 ret_pc: 0000000000575004  RPC:  l0: 0000000000000001 l1: 0000000000000000 l2: 0000000000160929 l3: 0000000000000001 l4: fffff800ee9ff334 l5: 0000000000000000 l6: 000000000000000f l7: fffff800ef827fd0 i0: fffff800eed8c660 i1: fffff800ee9ff2e0 i2: fffff800ed007ac0 i3: fffff800ee9ff320 i4: fffff80002cb7810 i5: fffff800eed04048 i6: fffff800ece126d1 i7: 00000000005755c0 I7:  Caller[00000000005755c0]: xlog_recover_do_buffer_trans+0x200/0x2e0  Caller[0000000000576428]: xlog_recover_do_trans+0x188/0x1a0  Caller[00000000005765b0]: xlog_recover_commit_trans+0x30/0x60  Caller[0000000000576700]: xlog_recover_process_data+0xe0/0x1e0  Caller[00000000005772fc]: xlog_do_recovery_pass+0x15c/0x680  Caller[00000000005778d8]: xlog_do_log_recovery+0xb8/0x120  Caller[0000000000577950]: xlog_do_recover+0x10/0x140  Caller[0000000000577b0c]: xlog_recover+0x8c/0xc0  Caller[000000000056f578]: xfs_log_mount+0x78/0x100  Caller[000000000057913c]: xfs_mountfs+0x53c/0xac0  Caller[000000000058000c]: xfs_mount+0x2cc/0x500  Caller[0000000000591d34]: vfs_mount+0x34/0x60  Caller[0000000000591af8]: linvfs_fill_super+0x98/0x280  Caller[000000000048b710]: get_sb_bdev+0xf0/0x140  Caller[000000000048b960]: do_kern_mount+0x40/0x100  Caller[00000000004a2154]: do_add_mount+0x54/0x160  Caller[00000000004a2410]: do_mount+0x110/0x180  Caller[000000000042877c]: sys32_mount+0xfc/0x1a0  Caller[0000000000410c74]: linux_sparc_syscall32+0x34/0x40  Caller[0000000000012658]: 0x12658  Instruction DUMP: 948aa01f 0248000d 92224003 8400a004 80a2601f 82103fff 8328400a 08400015  [?1l> [?1049l[detached] $  Script done on Fri Mar 12 00:42:21 2004 From owner-linux-xfs@oss.sgi.com Fri Mar 12 07:23:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 12 Mar 2004 07:23:56 -0800 (PST) Received: from localhost.localdomain (outgoingmail.adic.com [63.81.117.28]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2CFNmKO021843 for ; Fri, 12 Mar 2004 07:23:51 -0800 Received: from xfs.org (jen [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i2CFJqTo010803; Fri, 12 Mar 2004 09:19:58 -0600 Message-ID: <4051D517.4070005@xfs.org> Date: Fri, 12 Mar 2004 09:19:51 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: William Lee Irwin III CC: linux-xfs@oss.sgi.com Subject: Re: xfs recovery oops in 2.6.4-mm1 References: <20040312100025.GP655@holomorphy.com> In-Reply-To: <20040312100025.GP655@holomorphy.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2438 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 2418 Lines: 73 William Lee Irwin III wrote: > Console log attached. Remote kernel hacking -level access to the system > for debugging can be arranged. Hi, I see this is a sparc, any chance you could provide disassembly of the xfs_next_bit function. I wonder if it is playing up on this processor, it makes use of ffs and we have had some architecture issues with it before. Not that I can read sparc assembler, but I can take a crack at it ;-) Have you successfully used xfs on this box with older kernels, or is this a new filesystem? Was this the first mount under 2.6.4-mm1? Steve > > -- wli > >  > mount(272): Oops [#1] >  > TSTATE: 0000000011009601 TPC: 00000000005414d0 TNPC: 00000000005414d4 Y: 00000000 Not tainted >  > TPC: >  > g0: 0000000000000000 g1: 0000000000000000 g2: 0000000000000000 g3: 0000000000000000 > > g4: fffff800edc88140 g5: 0000000000000000 g6: fffff800ece10000 g7: fffff80002cb6810 > > o0: ffffffffffffffff o1: ffff001da00f6300 o2: 0000000000000001 o3: 0000000000000080 > > o4: 0000000000000080 o5: 0000000000200200 sp: fffff800ece12611 ret_pc: 0000000000575004 >  > RPC: >  > l0: 0000000000000001 l1: 0000000000000000 l2: 0000000000160929 l3: 0000000000000001 > > l4: fffff800ee9ff334 l5: 0000000000000000 l6: 000000000000000f l7: fffff800ef827fd0 > > i0: fffff800eed8c660 i1: fffff800ee9ff2e0 i2: fffff800ed007ac0 i3: fffff800ee9ff320 > > i4: fffff80002cb7810 i5: fffff800eed04048 i6: fffff800ece126d1 i7: 00000000005755c0 > > I7: >  > Caller[00000000005755c0]: xlog_recover_do_buffer_trans+0x200/0x2e0 >  > Caller[0000000000576428]: xlog_recover_do_trans+0x188/0x1a0 >  > Caller[00000000005765b0]: xlog_recover_commit_trans+0x30/0x60 >  > Caller[0000000000576700]: xlog_recover_process_data+0xe0/0x1e0 >  > Caller[00000000005772fc]: xlog_do_recovery_pass+0x15c/0x680 >  > Caller[00000000005778d8]: xlog_do_log_recovery+0xb8/0x120 >  > Caller[0000000000577950]: xlog_do_recover+0x10/0x140 >  > Caller[0000000000577b0c]: xlog_recover+0x8c/0xc0 >  > Caller[000000000056f578]: xfs_log_mount+0x78/0x100 >  > Caller[000000000057913c]: xfs_mountfs+0x53c/0xac0 >  > Caller[000000000058000c]: xfs_mount+0x2cc/0x500 >  > Caller[0000000000591d34]: vfs_mount+0x34/0x60 >  From owner-linux-xfs@oss.sgi.com Fri Mar 12 11:32:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 12 Mar 2004 11:32:58 -0800 (PST) Received: from atl-ms1.megatrends.com (mail2.megatrends.com [155.229.80.16]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2CJWtKO004684 for ; Fri, 12 Mar 2004 11:32:56 -0800 Received: by atl-ms1.megatrends.com with Internet Mail Service (5.5.2657.72) id ; Wed, 10 Mar 2004 14:38:07 -0500 Message-ID: <8CCBDD5583C50E4196F012E79439B45C04C9A322@atl-ms1.megatrends.com> From: Vinesh Christopher To: "'Mike Burger'" Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: Bug : XFS - XSCALE "Directory Not Empty" Date: Wed, 10 Mar 2004 14:38:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 2439 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vineshc@ami.com Precedence: bulk X-list: linux-xfs Content-Length: 3332 Lines: 121 Same result => rm: cannot remove directory 't' : Directory not empty But all the files are deleted and the directory is empty I tried rmdir t . It says Directory not empty -----Original Message----- From: Mike Burger [mailto:mburger@bubbanfriends.org] Sent: Wednesday, March 10, 2004 2:31 PM To: Vinesh Christopher Cc: 'linux-xfs@oss.sgi.com' Subject: Re: Bug : XFS - XSCALE "Directory Not Empty" What happens if you just try "rm -rf t"? On Wed, 10 Mar 2004, Vinesh Christopher wrote: > > Intel IQ80321 (Xscale) Evaluation Board > Running Linux 2.6.0 with -rmk2 patches > xfsprogs_2.6.3-1 is taken from debian > > I did the following > > # mkfs.xfs /dev/sda1 > # mount /dev/sda1 /mnt > # cd /mnt > # mkdir t > # cp /lib/* t > # rm -r -f t > rm: cannot remove directory 't' : Directory not empty > # > > But the directory is empty. Unmounted the filesystem > and ran xfs_repair -n /dev/sda1 which produced the following > output : > > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - scan filesystem freespace and inode maps... > - found root inode chunk > Phase 3 - for each AG... > - scan (but don't clear) agi unlinked lists... > - process known inodes and perform inode discovery... > - agno = 0 > size of entry #0 overflows space left in in shortform dir 131 > would junk 2 entries > would have corrected entry count in directory 131 from 2 to 0 > would have corrected directory 131 size from 30 to 8 > - agno = 1 > - agno = 2 > - agno = 3 > - agno = 4 > - agno = 5 > - agno = 6 > - agno = 7 > - process newly discovered inodes... > Phase 4 - check for duplicate blocks... > - setting up duplicate extent list... > - check for inodes claiming duplicate blocks... > - agno = 0 > entry " libwrap.so.0.7" in shortform directory 131 references non-existent > inod > e 18432 > size of entry #0 overflows space left in in shortform dir 131 > would junk 2 entries > would have corrected entry count in directory 131 from 2 to 0 > would have corrected directory 131 size from 30 to 8 > - agno = 1 > - agno = 2 > - agno = 3 > - agno = 4 > - agno = 5 > - agno = 6 > - agno = 7 > No modify flag set, skipping phase 5 > Phase 6 - check inode connectivity... > - traversing filesystem starting at / ... > - traversal finished ... > - traversing all unattached subtrees ... > - traversals finished ... > - moving disconnected inodes to lost+found ... > disconnected inode 267, would move to lost+found > disconnected inode 268, would move to lost+found > Phase 7 - verify link counts... > No modify flag set, skipping filesystem flush and exiting. > > > > I tried with 2.4.21 and XFS 1.3.1 patches -> same problem > > Anybody seen this? > > > Help!! > > > > > > [[HTML alternate version deleted]] > > -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Fri Mar 12 13:17:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 12 Mar 2004 13:17:40 -0800 (PST) Received: from mail.ocs.com.au (pr-117-210.ains.net.au [202.147.117.210] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2CLHQKO010052 for ; Fri, 12 Mar 2004 13:17:27 -0800 Received: from ocs3.ocs.com.au (ocs3.ocs.com.au [192.168.255.3]) by mail.ocs.com.au (Postfix) with ESMTP id B707D1800A6; Sat, 13 Mar 2004 08:17:21 +1100 (EST) Received: by ocs3.ocs.com.au (Postfix, from userid 16331) id 9AAFEC00AE; Sat, 13 Mar 2004 08:17:03 +1100 (EST) Received: from ocs3.ocs.com.au (localhost [127.0.0.1]) by ocs3.ocs.com.au (Postfix) with ESMTP id 67246140086; Sat, 13 Mar 2004 08:17:03 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Vinesh Christopher Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: Bug : XFS - XSCALE "Directory Not Empty" In-reply-to: Your message of "Wed, 10 Mar 2004 14:38:05 CDT." <8CCBDD5583C50E4196F012E79439B45C04C9A322@atl-ms1.megatrends.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Date: Sat, 13 Mar 2004 08:17:02 +1100 Message-ID: <7320.1079126222@ocs3.ocs.com.au> Content-Transfer-Encoding: 8bit X-archive-position: 2440 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 486 Lines: 11 On Wed, 10 Mar 2004 14:38:05 -0500, Vinesh Christopher wrote: >Same result => rm: cannot remove directory 't' : Directory not empty >But all the files are deleted and the directory is empty >I tried rmdir t . It says Directory not empty ls -la t and check the link count on the '.' file. An empty directory should have 2 links, any other value will prevent rmdir from deleting the directory. If the link count is wrong, unmount the filesystem and run xfs_repair. From owner-linux-xfs@oss.sgi.com Fri Mar 12 15:32:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 12 Mar 2004 15:32:01 -0800 (PST) Received: from holomorphy.com (mail@holomorphy.com [207.189.100.168]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2CNVxKO013591 for ; Fri, 12 Mar 2004 15:32:00 -0800 Received: from wli by holomorphy.com with local (Exim 3.36 #1 (Debian)) id 1B1w89-00071t-00; Fri, 12 Mar 2004 15:31:53 -0800 Date: Fri, 12 Mar 2004 15:31:53 -0800 From: William Lee Irwin III To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: xfs recovery oops in 2.6.4-mm1 Message-ID: <20040312233153.GT655@holomorphy.com> References: <20040312100025.GP655@holomorphy.com> <4051D517.4070005@xfs.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4051D517.4070005@xfs.org> Organization: The Domain of Holomorphy User-Agent: Mutt/1.5.5.1+cvs20040105i Content-Transfer-Encoding: 8bit X-archive-position: 2441 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wli@holomorphy.com Precedence: bulk X-list: linux-xfs Content-Length: 735 Lines: 19 > William Lee Irwin III wrote: > >Console log attached. Remote kernel hacking -level access to the system > >for debugging can be arranged. On Fri, Mar 12, 2004 at 09:19:51AM -0600, Steve Lord wrote: > I see this is a sparc, any chance you could provide disassembly of the > xfs_next_bit function. I wonder if it is playing up on this processor, > it makes use of ffs and we have had some architecture issues with it > before. > Not that I can read sparc assembler, but I can take a crack at it ;-) > Have you successfully used xfs on this box with older kernels, or is > this a new filesystem? Was this the first mount under 2.6.4-mm1? It holds up under normal usage. It seems that recovery is the only time this happens. -- wli From owner-linux-xfs@oss.sgi.com Fri Mar 12 15:39:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 12 Mar 2004 15:39:19 -0800 (PST) Received: from holomorphy.com (mail@holomorphy.com [207.189.100.168]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2CNdEKO014074 for ; Fri, 12 Mar 2004 15:39:14 -0800 Received: from wli by holomorphy.com with local (Exim 3.36 #1 (Debian)) id 1B1wFB-0007I1-00; Fri, 12 Mar 2004 15:39:09 -0800 Date: Fri, 12 Mar 2004 15:39:09 -0800 From: William Lee Irwin III To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: xfs recovery oops in 2.6.4-mm1 Message-ID: <20040312233909.GU655@holomorphy.com> References: <20040312100025.GP655@holomorphy.com> <4051D517.4070005@xfs.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4051D517.4070005@xfs.org> Organization: The Domain of Holomorphy User-Agent: Mutt/1.5.5.1+cvs20040105i Content-Transfer-Encoding: 8bit X-archive-position: 2442 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wli@holomorphy.com Precedence: bulk X-list: linux-xfs Content-Length: 23849 Lines: 514 On Fri, Mar 12, 2004 at 09:19:51AM -0600, Steve Lord wrote: > I see this is a sparc, any chance you could provide disassembly of the > xfs_next_bit function. I wonder if it is playing up on this processor, > it makes use of ffs and we have had some architecture issues with it > before. > Not that I can read sparc assembler, but I can take a crack at it ;-) > Have you successfully used xfs on this box with older kernels, or is > this a new filesystem? Was this the first mount under 2.6.4-mm1? Here's the disassembly-like stuff. -- wli 00000000005414a0 : 5414a0: 83 32 a0 05 srl %o2, 5, %g1 5414a4: 8a 10 00 08 mov %o0, %g5 5414a8: 83 28 70 02 sllx %g1, 2, %g1 5414ac: 86 0a bf e0 and %o2, -32, %g3 5414b0: 93 2a 60 05 sll %o1, 5, %o1 5414b4: 90 10 3f ff mov -1, %o0 5414b8: 80 a2 80 09 cmp %o2, %o1 5414bc: 1a 40 00 2e bcc,pn %icc, 541574 5414c0: 84 01 40 01 add %g5, %g1, %g2 5414c4: 94 8a a0 1f andcc %o2, 0x1f, %o2 5414c8: 02 48 00 0d be %icc, 5414fc 5414cc: 92 22 40 03 sub %o1, %g3, %o1 5414d0: d0 01 40 01 ld [ %g5 + %g1 ], %o0 5414d4: 84 00 a0 04 add %g2, 4, %g2 5414d8: 80 a2 60 1f cmp %o1, 0x1f 5414dc: 82 10 3f ff mov -1, %g1 5414e0: 83 28 40 0a sll %g1, %o2, %g1 5414e4: 08 40 00 15 bleu,pn %icc, 541538 5414e8: 90 0a 00 01 and %o0, %g1, %o0 5414ec: 80 a2 20 00 cmp %o0, 0 5414f0: 12 40 00 15 bne,pn %icc, 541544 5414f4: 92 02 7f e0 add %o1, -32, %o1 5414f8: 86 00 e0 20 add %g3, 0x20, %g3 5414fc: 80 a2 60 1f cmp %o1, 0x1f 541500: 08 40 00 0b bleu,pn %icc, 54152c 541504: 80 a2 60 00 cmp %o1, 0 541508: d0 00 80 00 ld [ %g2 ], %o0 54150c: 92 02 7f e0 add %o1, -32, %o1 541510: 80 a2 20 00 cmp %o0, 0 541514: 12 40 00 0c bne,pn %icc, 541544 541518: 84 00 a0 04 add %g2, 4, %g2 54151c: 80 a2 60 1f cmp %o1, 0x1f 541520: 18 4f ff fa bgu %icc, 541508 541524: 86 00 e0 20 add %g3, 0x20, %g3 541528: 80 a2 60 00 cmp %o1, 0 54152c: 02 40 00 12 be,pn %icc, 541574 541530: 90 10 3f ff mov -1, %o0 541534: d0 00 80 00 ld [ %g2 ], %o0 541538: 80 a2 20 00 cmp %o0, 0 54153c: 02 48 00 0b be %icc, 541568 541540: 82 10 20 00 clr %g1 541544: 91 3a 20 00 sra %o0, 0, %o0 541548: 82 0a 20 01 and %o0, 1, %g1 54154c: 0a c0 40 06 brnz,pn %g1, 541564 541550: 84 10 20 00 clr %g2 541554: 91 32 30 01 srlx %o0, 1, %o0 541558: 82 0a 20 01 and %o0, 1, %g1 54155c: 02 f8 7f fe brz %g1, 541554 541560: 84 00 a0 01 inc %g2 541564: 82 00 a0 01 add %g2, 1, %g1 541568: 82 00 c0 01 add %g3, %g1, %g1 54156c: 82 00 7f ff add %g1, -1, %g1 541570: 91 38 60 00 sra %g1, 0, %o0 541574: 81 c3 e0 08 retl 541578: 01 00 00 00 nop 54157c: 01 00 00 00 nop 0000000000541580 : 541580: 05 00 00 3f sethi %hi(0xfc00), %g2 541584: 03 3f ff c0 sethi %hi(0xffff0000), %g1 541588: 8a 10 a3 ff or %g2, 0x3ff, %g5 54158c: 80 8a 00 01 btst %o0, %g1 541590: 02 48 00 0e be %icc, 5415c8 541594: 86 10 3f ff mov -1, %g3 541598: 03 3f c0 00 sethi %hi(0xff000000), %g1 54159c: 8a 10 20 18 mov 0x18, %g5 5415a0: 80 8a 00 01 btst %o0, %g1 5415a4: 8b 64 60 10 move %icc, 0x10, %g5 5415a8: 83 32 00 05 srl %o0, %g5, %g1 5415ac: 05 00 1b 01 sethi %hi(0x6c0400), %g2 5415b0: 82 08 60 ff and %g1, 0xff, %g1 5415b4: 84 10 a3 a0 or %g2, 0x3a0, %g2 5415b8: c6 08 80 01 ldub [ %g2 + %g1 ], %g3 5415bc: 86 01 40 03 add %g5, %g3, %g3 5415c0: 10 68 00 09 b %xcc, 5415e4 5415c4: 87 38 e0 00 sra %g3, 0, %g3 5415c8: 80 8a 00 05 btst %o0, %g5 5415cc: 02 40 00 06 be,pn %icc, 5415e4 5415d0: 82 10 a3 00 or %g2, 0x300, %g1 5415d4: 8a 10 20 08 mov 8, %g5 5415d8: 80 8a 00 01 btst %o0, %g1 5415dc: 10 6f ff f3 b %xcc, 5415a8 5415e0: 8b 64 60 00 move %icc, 0, %g5 5415e4: 81 c3 e0 08 retl 5415e8: 90 10 00 03 mov %g3, %o0 5415ec: 30 68 00 05 b,a %xcc, 541600 5415f0: 01 00 00 00 nop 5415f4: 01 00 00 00 nop 5415f8: 01 00 00 00 nop 5415fc: 01 00 00 00 nop 541600: 00 54 1e 48 bn,pn %icc, 448f20 541604: 00 54 20 24 bn,pn %icc, 449694 541608: 00 54 20 24 bn,pn %icc, 449698 54160c: 00 54 20 24 bn,pn %icc, 44969c 541610: 00 54 20 c8 bn,pn %icc, 449930 541614: 00 54 22 7c bn,pn %icc, 44a004 541618: 00 54 20 24 bn,pn %icc, 4496a8 54161c: 00 54 20 24 bn,pn %icc, 4496ac 541620: 00 54 23 98 bn,pn %icc, 44a480 541624: 00 54 20 24 bn,pn %icc, 4496b4 541628: 00 54 25 30 bn,pn %icc, 44aae8 54162c: 00 54 20 24 bn,pn %icc, 4496bc 541630: 00 54 25 c0 bn,pn %icc, 44ad30 541634: 00 54 26 28 bn,pn %icc, 44aed4 541638: 00 54 26 9c bn,pn %icc, 44b0a8 54163c: 00 54 1d 54 bn,pn %icc, 448b8c 541640: 00 54 2a c4 bn,pn %icc, 44c150 541644: 00 54 2a bc bn,pn %icc, 44c134 541648: 00 54 2a bc bn,pn %icc, 44c138 54164c: 00 54 2a bc bn,pn %icc, 44c13c 541650: 00 54 2c 34 bn,pn %icc, 44c720 541654: 00 54 2c f0 bn,pn %icc, 44ca14 541658: 00 54 2a bc bn,pn %icc, 44c148 54165c: 00 54 2a bc bn,pn %icc, 44c14c 541660: 00 54 2d f0 bn,pn %icc, 44ce20 541664: 00 54 2a bc bn,pn %icc, 44c154 541668: 00 54 2e c0 bn,pn %icc, 44d168 54166c: 00 54 2a bc bn,pn %icc, 44c15c 541670: 00 54 2f 98 bn,pn %icc, 44d4d0 541674: 00 54 2f f4 bn,pn %icc, 44d644 541678: 00 54 30 a8 bn,pn %icc, 44d918 54167c: 00 54 29 a4 bn,pn %icc, 44bd0c 0000000000541680 : 541680: 9d e3 bf 20 save %sp, -224, %sp 541684: c2 0e 62 0a ldub [ %i1 + 0x20a ], %g1 541688: 9a 10 00 19 mov %i1, %o5 54168c: 92 10 00 18 mov %i0, %o1 541690: d0 5e 60 28 ldx [ %i1 + 0x28 ], %o0 541694: 80 a0 60 00 cmp %g1, 0 541698: 02 48 00 34 be %icc, 541768 54169c: c4 56 60 a0 ldsh [ %i1 + 0xa0 ], %g2 5416a0: 83 28 60 03 sll %g1, 3, %g1 5416a4: 80 a0 80 01 cmp %g2, %g1 5416a8: 14 48 00 07 bg %icc, 5416c4 5416ac: 94 10 20 00 clr %o2 5416b0: c2 07 00 00 ld [ %i4 ], %g1 5416b4: 82 10 60 08 or %g1, 8, %g1 5416b8: c2 27 00 00 st %g1, [ %i4 ] 5416bc: 10 68 00 2d b %xcc, 541770 5416c0: b0 10 20 00 clr %i0 5416c4: 96 10 20 00 clr %o3 5416c8: c0 73 a8 af clrx [ %sp + 0x8af ] 5416cc: 40 00 2f 65 call 54d460 5416d0: 98 10 20 02 mov 2, %o4 5416d4: f6 72 20 a8 stx %i3, [ %o0 + 0xa8 ] 5416d8: 98 07 a7 eb add %fp, 0x7eb, %o4 5416dc: 92 10 20 00 clr %o1 5416e0: c2 5e 80 00 ldx [ %i2 ], %g1 5416e4: 94 10 20 00 clr %o2 5416e8: 96 10 20 00 clr %o3 5416ec: b2 10 00 08 mov %o0, %i1 5416f0: 40 00 2b bc call 54c5e0 5416f4: c2 72 20 b0 stx %g1, [ %o0 + 0xb0 ] 5416f8: b0 92 20 00 orcc %o0, 0, %i0 5416fc: 12 40 00 16 bne,pn %icc, 541754 541700: 92 10 00 1c mov %i4, %o1 541704: 90 10 00 19 mov %i1, %o0 541708: 40 00 2b d6 call 54c660 54170c: 94 07 a7 eb add %fp, 0x7eb, %o2 541710: b0 92 20 00 orcc %o0, 0, %i0 541714: 12 40 00 10 bne,pn %icc, 541754 541718: c2 07 a7 eb ld [ %fp + 0x7eb ], %g1 54171c: 80 a0 60 00 cmp %g1, 0 541720: 02 40 00 09 be,pn %icc, 541744 541724: 90 10 00 19 mov %i1, %o0 541728: c2 5e 60 b0 ldx [ %i1 + 0xb0 ], %g1 54172c: 92 10 20 00 clr %o1 541730: c2 76 80 00 stx %g1, [ %i2 ] 541734: 40 00 2e 7b call 54d120 541738: c0 26 60 b8 clr [ %i1 + 0xb8 ] 54173c: 10 68 00 0d b %xcc, 541770 541740: b0 10 20 00 clr %i0 541744: 40 00 2e 77 call 54d120 541748: 92 10 20 00 clr %o1 54174c: 10 68 00 09 b %xcc, 541770 541750: b0 10 20 1c mov 0x1c, %i0 541754: 90 10 00 19 mov %i1, %o0 541758: 40 00 2e 72 call 54d120 54175c: 92 10 20 01 mov 1, %o1 541760: 10 68 00 04 b %xcc, 541770 541764: b1 3e 20 00 sra %i0, 0, %i0 541768: 10 6f ff cf b %xcc, 5416a4 54176c: c2 02 22 d4 ld [ %o0 + 0x2d4 ], %g1 541770: 81 cf e0 08 rett %i7 + 8 541774: 01 00 00 00 nop 541778: 01 00 00 00 nop 54177c: 01 00 00 00 nop 0000000000541780 : 541780: 9d e3 bf 20 save %sp, -224, %sp 541784: c4 46 62 04 ldsw [ %i1 + 0x204 ], %g2 541788: 92 10 00 19 mov %i1, %o1 54178c: 90 10 20 00 clr %o0 541790: 94 10 00 1a mov %i2, %o2 541794: 96 10 00 1b mov %i3, %o3 541798: c2 0e 62 0a ldub [ %i1 + 0x20a ], %g1 54179c: 87 28 b0 04 sllx %g2, 4, %g3 5417a0: 80 a0 60 00 cmp %g1, 0 5417a4: 02 48 00 18 be %icc, 541804 5417a8: 85 28 60 03 sll %g1, 3, %g2 5417ac: 83 38 a0 00 sra %g2, 0, %g1 5417b0: 80 a0 c0 01 cmp %g3, %g1 5417b4: 08 68 00 18 bleu %xcc, 541814 5417b8: 98 07 a7 e7 add %fp, 0x7e7, %o4 5417bc: 90 10 00 18 mov %i0, %o0 5417c0: f8 73 a8 af stx %i4, [ %sp + 0x8af ] 5417c4: 9a 10 20 00 clr %o5 5417c8: c0 77 a7 e7 clrx [ %fp + 0x7e7 ] 5417cc: 40 00 0e 75 call 5451a0 5417d0: c0 73 a8 b7 clrx [ %sp + 0x8b7 ] 5417d4: c2 5f a7 e7 ldx [ %fp + 0x7e7 ], %g1 5417d8: b0 10 00 08 mov %o0, %i0 5417dc: 0a c0 40 04 brnz,pn %g1, 5417ec 5417e0: 80 a0 00 08 cmp %g0, %o0 5417e4: 10 68 00 0c b %xcc, 541814 5417e8: 91 3e 20 00 sra %i0, 0, %o0 5417ec: c0 20 60 b8 clr [ %g1 + 0xb8 ] 5417f0: d0 5f a7 e7 ldx [ %fp + 0x7e7 ], %o0 5417f4: 40 00 2e 4b call 54d120 5417f8: 92 40 20 00 addc %g0, 0, %o1 5417fc: 10 68 00 06 b %xcc, 541814 541800: 91 3e 20 00 sra %i0, 0, %o0 541804: c2 5e 60 28 ldx [ %i1 + 0x28 ], %g1 541808: c4 40 62 d4 ldsw [ %g1 + 0x2d4 ], %g2 54180c: 10 6f ff ea b %xcc, 5417b4 541810: 80 a0 c0 02 cmp %g3, %g2 541814: 81 c7 e0 08 ret 541818: 91 e8 00 08 restore %g0, %o0, %o0 54181c: 01 00 00 00 nop 0000000000541820 : 541820: 9d e3 be c0 save %sp, -320, %sp 541824: c2 0e 62 0a ldub [ %i1 + 0x20a ], %g1 541828: 90 10 20 00 clr %o0 54182c: 98 10 00 1c mov %i4, %o4 541830: c6 06 60 90 ld [ %i1 + 0x90 ], %g3 541834: 80 a0 60 00 cmp %g1, 0 541838: 12 48 00 04 bne %icc, 541848 54183c: 85 28 60 03 sll %g1, 3, %g2 541840: c2 5e 60 28 ldx [ %i1 + 0x28 ], %g1 541844: c4 00 62 d4 ld [ %g1 + 0x2d4 ], %g2 541848: 80 a0 c0 02 cmp %g3, %g2 54184c: 04 48 00 1f ble %icc, 5418c8 541850: 05 00 00 3c sethi %hi(0xf000), %g2 541854: c2 16 61 ba lduh [ %i1 + 0x1ba ], %g1 541858: b8 07 a7 6f add %fp, 0x76f, %i4 54185c: 07 00 00 10 sethi %hi(0x4000), %g3 541860: 92 10 20 80 mov 0x80, %o1 541864: 82 08 40 02 and %g1, %g2, %g1 541868: 90 10 00 1c mov %i4, %o0 54186c: 94 10 00 1a mov %i2, %o2 541870: 96 10 20 01 mov 1, %o3 541874: 80 a0 40 03 cmp %g1, %g3 541878: 02 40 00 07 be,pn %icc, 541894 54187c: 9a 10 20 00 clr %o5 541880: 90 10 00 18 mov %i0, %o0 541884: 40 00 0f 57 call 5455e0 541888: 92 10 00 19 mov %i1, %o1 54188c: 10 68 00 0f b %xcc, 5418c8 541890: 91 3a 20 00 sra %o0, 0, %o0 541894: 40 01 ab ae call 5ac74c <__bzero> 541898: e0 5e 60 28 ldx [ %i1 + 0x28 ], %l0 54189c: f4 77 a7 a7 stx %i2, [ %fp + 0x7a7 ] 5418a0: f6 77 a7 af stx %i3, [ %fp + 0x7af ] 5418a4: f2 77 a7 9f stx %i1, [ %fp + 0x79f ] 5418a8: c2 04 23 d4 ld [ %l0 + 0x3d4 ], %g1 5418ac: f0 77 a7 b7 stx %i0, [ %fp + 0x7b7 ] 5418b0: c2 27 a7 bf st %g1, [ %fp + 0x7bf ] 5418b4: c0 27 a7 c3 clr [ %fp + 0x7c3 ] 5418b8: c2 5c 23 c8 ldx [ %l0 + 0x3c8 ], %g1 5418bc: 9f c0 40 00 call %g1 5418c0: 90 10 00 1c mov %i4, %o0 5418c4: 91 3a 20 00 sra %o0, 0, %o0 5418c8: 81 c7 e0 08 ret 5418cc: 91 e8 00 08 restore %g0, %o0, %o0 5418d0: 30 68 00 04 b,a %xcc, 5418e0 5418d4: 01 00 00 00 nop 5418d8: 01 00 00 00 nop 5418dc: 01 00 00 00 nop 00000000005418e0 : 5418e0: 9d e3 be e0 save %sp, -288, %sp 5418e4: c6 09 a0 10 ldub [ %g6 + 0x10 ], %g3 5418e8: 03 00 1e 78 sethi %hi(0x79e000), %g1 5418ec: 05 00 1e 72 sethi %hi(0x79c800), %g2 5418f0: 82 10 60 18 or %g1, 0x18, %g1 5418f4: 84 10 a1 38 or %g2, 0x138, %g2 5418f8: e4 07 a8 bb ld [ %fp + 0x8bb ], %l2 5418fc: 87 28 f0 03 sllx %g3, 3, %g3 541900: e8 07 a8 c3 ld [ %fp + 0x8c3 ], %l4 541904: 92 10 00 19 mov %i1, %o1 541908: ca 58 40 03 ldx [ %g1 + %g3 ], %g5 54190c: a2 06 20 90 add %i0, 0x90, %l1 541910: 80 a4 a0 00 cmp %l2, 0 541914: 84 00 80 05 add %g2, %g5, %g2 541918: c2 00 a0 2c ld [ %g2 + 0x2c ], %g1 54191c: 82 00 60 01 inc %g1 541920: c2 20 a0 2c st %g1, [ %g2 + 0x2c ] 541924: c4 5e 80 00 ldx [ %i2 ], %g2 541928: 02 48 00 03 be %icc, 541934 54192c: c4 77 a7 bf stx %g2, [ %fp + 0x7bf ] 541930: e2 5e 20 88 ldx [ %i0 + 0x88 ], %l1 541934: c2 04 40 00 ld [ %l1 ], %g1 541938: a6 10 20 00 clr %l3 54193c: a0 10 20 00 clr %l0 541940: 8b 30 60 04 srl %g1, 4, %g5 541944: 80 a1 60 00 cmp %g5, 0 541948: 02 40 00 93 be,pn %icc, 541b94 54194c: c0 77 a7 b7 clrx [ %fp + 0x7b7 ] 541950: 05 00 03 ff sethi %hi(0xffc00), %g2 541954: c2 5e e0 08 ldx [ %i3 + 8 ], %g1 541958: 07 3f ff 80 sethi %hi(0xfffe0000), %g3 54195c: 84 10 a3 ff or %g2, 0x3ff, %g2 541960: 85 28 b0 20 sllx %g2, 0x20, %g2 541964: a0 00 80 03 add %g2, %g3, %l0 541968: 82 08 40 10 and %g1, %l0, %g1 54196c: 80 a0 40 10 cmp %g1, %l0 541970: 02 60 00 81 be,pn %xcc, 541b74 541974: d4 5f a7 bf ldx [ %fp + 0x7bf ], %o2 541978: 80 a2 40 05 cmp %o1, %g5 54197c: 02 40 00 7a be,pn %icc, 541b64 541980: b3 3a 60 00 sra %o1, 0, %i1 541984: d0 5c 60 18 ldx [ %l1 + 0x18 ], %o0 541988: 92 07 a7 cf add %fp, 0x7cf, %o1 54198c: 83 2e 70 04 sllx %i1, 4, %g1 541990: 40 00 29 7c call 54bf80 541994: 90 02 00 01 add %o0, %g1, %o0 541998: c2 5e e0 08 ldx [ %i3 + 8 ], %g1 54199c: 82 08 40 10 and %g1, %l0, %g1 5419a0: 80 a0 40 10 cmp %g1, %l0 5419a4: 02 60 00 67 be,pn %xcc, 541b40 5419a8: c6 5f a7 cf ldx [ %fp + 0x7cf ], %g3 5419ac: c2 5e c0 00 ldx [ %i3 ], %g1 5419b0: c4 5e e0 10 ldx [ %i3 + 0x10 ], %g2 5419b4: 82 00 40 02 add %g1, %g2, %g1 5419b8: 80 a0 40 03 cmp %g1, %g3 5419bc: 08 68 00 62 bleu %xcc, 541b44 5419c0: 9b 3c a0 00 sra %l2, 0, %o5 5419c4: c2 07 a7 e7 ld [ %fp + 0x7e7 ], %g1 5419c8: 80 a0 60 01 cmp %g1, 1 5419cc: 02 40 00 06 be,pn %icc, 5419e4 5419d0: c6 5f a7 d7 ldx [ %fp + 0x7d7 ], %g3 5419d4: 82 08 c0 10 and %g3, %l0, %g1 5419d8: 80 a0 40 10 cmp %g1, %l0 5419dc: 02 60 00 46 be,pn %xcc, 541af4 5419e0: 05 3f fc 00 sethi %hi(0xfff00000), %g2 5419e4: 92 10 00 19 mov %i1, %o1 5419e8: 96 10 00 1b mov %i3, %o3 5419ec: 90 10 00 18 mov %i0, %o0 5419f0: 94 07 a7 bf add %fp, 0x7bf, %o2 5419f4: 40 00 03 a3 call 542880 5419f8: 98 07 a7 cb add %fp, 0x7cb, %o4 5419fc: a0 92 20 00 orcc %o0, 0, %l0 541a00: 12 40 00 84 bne,pn %icc, 541c10 541a04: c4 07 a7 cb ld [ %fp + 0x7cb ], %g2 541a08: 80 a4 a0 00 cmp %l2, 0 541a0c: 32 48 00 03 bne,a %icc, 541a18 541a10: c2 4e 22 0b ldsb [ %i0 + 0x20b ], %g1 541a14: c2 4e 21 bd ldsb [ %i0 + 0x1bd ], %g1 541a18: 80 a0 60 02 cmp %g1, 2 541a1c: 02 40 00 1b be,pn %icc, 541a88 541a20: 80 a4 a0 00 cmp %l2, 0 541a24: 0a cc c0 04 brnz %l3, 541a34 541a28: c2 5f a7 b7 ldx [ %fp + 0x7b7 ], %g1 541a2c: 02 c8 40 0a brz %g1, 541a54 541a30: c4 5f a7 bf ldx [ %fp + 0x7bf ], %g2 541a34: c4 5f a7 bf ldx [ %fp + 0x7bf ], %g2 541a38: 02 c8 80 04 brz %g2, 541a48 541a3c: 94 10 00 01 mov %g1, %o2 541a40: c2 40 a0 b8 ldsw [ %g2 + 0xb8 ], %g1 541a44: 94 02 80 01 add %o2, %g1, %o2 541a48: 80 a2 80 13 cmp %o2, %l3 541a4c: 2a 60 00 08 bcs,a,pn %xcc, 541a6c 541a50: 94 24 c0 0a sub %l3, %o2, %o2 541a54: 22 c8 80 6f brz,a %g2, 541c10 541a58: c4 07 a7 cb ld [ %fp + 0x7cb ], %g2 541a5c: c0 20 a0 b8 clr [ %g2 + 0xb8 ] 541a60: c2 5f a7 bf ldx [ %fp + 0x7bf ], %g1 541a64: 10 68 00 6a b %xcc, 541c0c 541a68: c2 76 80 00 stx %g1, [ %i2 ] 541a6c: d0 5e 20 28 ldx [ %i0 + 0x28 ], %o0 541a70: 92 10 20 1e mov 0x1e, %o1 541a74: 95 3a a0 00 sra %o2, 0, %o2 541a78: 40 00 e0 82 call 579c80 541a7c: 97 3d 20 00 sra %l4, 0, %o3 541a80: 10 6f ff f5 b %xcc, 541a54 541a84: c4 5f a7 bf ldx [ %fp + 0x7bf ], %g2 541a88: 12 48 00 19 bne %icc, 541aec 541a8c: c4 0c 60 13 ldub [ %l1 + 0x13 ], %g2 541a90: c2 06 22 04 ld [ %i0 + 0x204 ], %g1 541a94: 80 a0 40 02 cmp %g1, %g2 541a98: 04 4f ff e3 ble %icc, 541a24 541a9c: 9a 10 20 00 clr %o5 541aa0: d0 5e 20 d0 ldx [ %i0 + 0xd0 ], %o0 541aa4: 82 07 a7 b3 add %fp, 0x7b3, %g1 541aa8: 9b 7c f4 01 movrne %l3, 1, %o5 541aac: 85 3c a0 00 sra %l2, 0, %g2 541ab0: 94 10 00 1c mov %i4, %o2 541ab4: c2 73 a8 af stx %g1, [ %sp + 0x8af ] 541ab8: 96 10 00 1d mov %i5, %o3 541abc: 92 10 00 18 mov %i0, %o1 541ac0: c4 73 a8 b7 stx %g2, [ %sp + 0x8b7 ] 541ac4: 40 00 0d b7 call 5451a0 541ac8: 98 07 a7 bf add %fp, 0x7bf, %o4 541acc: c4 07 a7 b3 ld [ %fp + 0x7b3 ], %g2 541ad0: c2 07 a7 cb ld [ %fp + 0x7cb ], %g1 541ad4: a0 92 20 00 orcc %o0, 0, %l0 541ad8: 82 10 40 02 or %g1, %g2, %g1 541adc: 02 4f ff d2 be %icc, 541a24 541ae0: c2 27 a7 cb st %g1, [ %fp + 0x7cb ] 541ae4: 10 68 00 4b b %xcc, 541c10 541ae8: c4 07 a7 cb ld [ %fp + 0x7cb ], %g2 541aec: 10 6f ff ea b %xcc, 541a94 541af0: c2 56 22 08 ldsh [ %i0 + 0x208 ], %g1 541af4: 03 00 00 7f sethi %hi(0x1fc00), %g1 541af8: fa 73 a8 af stx %i5, [ %sp + 0x8af ] 541afc: 82 10 63 ff or %g1, 0x3ff, %g1 541b00: 92 10 00 19 mov %i1, %o1 541b04: 85 28 b0 20 sllx %g2, 0x20, %g2 541b08: 96 10 00 1b mov %i3, %o3 541b0c: 84 00 80 01 add %g2, %g1, %g2 541b10: 90 10 00 18 mov %i0, %o0 541b14: 94 07 a7 bf add %fp, 0x7bf, %o2 541b18: 98 07 a7 b7 add %fp, 0x7b7, %o4 541b1c: 9a 10 00 1c mov %i4, %o5 541b20: a6 08 c0 02 and %g3, %g2, %l3 541b24: 83 3d 20 00 sra %l4, 0, %g1 541b28: 84 07 a7 cb add %fp, 0x7cb, %g2 541b2c: c2 73 a8 bf stx %g1, [ %sp + 0x8bf ] 541b30: 40 00 00 44 call 541c40 541b34: c4 73 a8 b7 stx %g2, [ %sp + 0x8b7 ] 541b38: 10 6f ff b2 b %xcc, 541a00 541b3c: a0 92 20 00 orcc %o0, 0, %l0 541b40: 9b 3c a0 00 sra %l2, 0, %o5 541b44: 92 10 00 19 mov %i1, %o1 541b48: 96 10 00 1b mov %i3, %o3 541b4c: d4 5f a7 bf ldx [ %fp + 0x7bf ], %o2 541b50: 90 10 00 18 mov %i0, %o0 541b54: 40 00 06 c3 call 543660 541b58: 98 07 a7 cb add %fp, 0x7cb, %o4 541b5c: 10 6f ff a9 b %xcc, 541a00 541b60: a0 92 20 00 orcc %o0, 0, %l0 541b64: 93 3a 60 00 sra %o1, 0, %o1 541b68: 96 10 00 1b mov %i3, %o3 541b6c: 10 6f ff f8 b %xcc, 541b4c 541b70: 9b 3c a0 00 sra %l2, 0, %o5 541b74: 93 3a 60 00 sra %o1, 0, %o1 541b78: 96 10 00 1b mov %i3, %o3 541b7c: 9b 3d 20 00 sra %l4, 0, %o5 541b80: 90 10 00 18 mov %i0, %o0 541b84: 40 00 05 c7 call 5432a0 541b88: 98 07 a7 cb add %fp, 0x7cb, %o4 541b8c: 10 6f ff 9d b %xcc, 541a00 541b90: a0 92 20 00 orcc %o0, 0, %l0 541b94: 99 3c a0 00 sra %l2, 0, %o4 541b98: 90 10 00 18 mov %i0, %o0 541b9c: 92 10 20 00 clr %o1 541ba0: 94 10 20 01 mov 1, %o2 541ba4: 40 00 0e 67 call 545540 541ba8: 96 10 00 1b mov %i3, %o3 541bac: c0 24 60 14 clr [ %l1 + 0x14 ] 541bb0: 03 00 03 ff sethi %hi(0xffc00), %g1 541bb4: c6 5e e0 08 ldx [ %i3 + 8 ], %g3 541bb8: 05 3f ff 80 sethi %hi(0xfffe0000), %g2 541bbc: 82 10 63 ff or %g1, 0x3ff, %g1 541bc0: 83 28 70 20 sllx %g1, 0x20, %g1 541bc4: 82 00 40 02 add %g1, %g2, %g1 541bc8: 86 08 c0 01 and %g3, %g1, %g3 541bcc: 80 a0 c0 01 cmp %g3, %g1 541bd0: 02 60 00 0d be,pn %xcc, 541c04 541bd4: 80 a4 a0 00 cmp %l2, 0 541bd8: 12 48 00 09 bne %icc, 541bfc 541bdc: 82 10 20 01 mov 1, %g1 541be0: 82 10 20 01 mov 1, %g1 541be4: c2 26 22 04 st %g1, [ %i0 + 0x204 ] 541be8: 82 10 20 05 mov 5, %g1 541bec: 80 a4 a0 00 cmp %l2, 0 541bf0: 83 66 60 81 movne %icc, 0x81, %g1 541bf4: 10 6f ff 86 b %xcc, 541a0c 541bf8: c2 27 a7 cb st %g1, [ %fp + 0x7cb ] 541bfc: 10 6f ff fb b %xcc, 541be8 541c00: c2 36 22 08 sth %g1, [ %i0 + 0x208 ] 541c04: 10 6f ff 81 b %xcc, 541a08 541c08: c0 27 a7 cb clr [ %fp + 0x7cb ] 541c0c: c4 07 a7 cb ld [ %fp + 0x7cb ], %g2 541c10: b1 3c 20 00 sra %l0, 0, %i0 541c14: c2 5f a8 af ldx [ %fp + 0x8af ], %g1 541c18: c4 20 40 00 st %g2, [ %g1 ] 541c1c: 81 cf e0 08 rett %i7 + 8 541c20: 01 00 00 00 nop 541c24: 30 68 00 07 b,a %xcc, 541c40 541c28: 01 00 00 00 nop 541c2c: 01 00 00 00 nop 541c30: 01 00 00 00 nop 541c34: 01 00 00 00 nop 541c38: 01 00 00 00 nop 541c3c: 01 00 00 00 nop From owner-linux-xfs@oss.sgi.com Fri Mar 12 19:44:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 12 Mar 2004 19:44:11 -0800 (PST) Received: from relay02.roc.ny.frontiernet.net (relay02.roc.ny.frontiernet.net [66.133.131.35]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2D3i7KO022809 for ; Fri, 12 Mar 2004 19:44:08 -0800 Received: (qmail 22415 invoked from network); 13 Mar 2004 03:44:06 -0000 Received: from unknown (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay02.roc.ny.frontiernet.net (FrontierMTA 2.3.7a) with SMTP for ; 13 Mar 2004 03:44:06 -0000 Message-ID: <4052834B.5010208@xfs.org> Date: Fri, 12 Mar 2004 21:43:07 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: William Lee Irwin III CC: linux-xfs@oss.sgi.com, Nathan Scott Subject: Re: xfs recovery oops in 2.6.4-mm1 References: <20040312100025.GP655@holomorphy.com> <4051D517.4070005@xfs.org> <20040312233153.GT655@holomorphy.com> In-Reply-To: <20040312233153.GT655@holomorphy.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2443 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 2322 Lines: 73 William Lee Irwin III wrote: >>William Lee Irwin III wrote: >> >>>Console log attached. Remote kernel hacking -level access to the system >>>for debugging can be arranged. > > > On Fri, Mar 12, 2004 at 09:19:51AM -0600, Steve Lord wrote: > >>I see this is a sparc, any chance you could provide disassembly of the >>xfs_next_bit function. I wonder if it is playing up on this processor, >>it makes use of ffs and we have had some architecture issues with it >>before. >>Not that I can read sparc assembler, but I can take a crack at it ;-) >>Have you successfully used xfs on this box with older kernels, or is >>this a new filesystem? Was this the first mount under 2.6.4-mm1? > > > It holds up under normal usage. It seems that recovery is the only time > this happens. > > > -- wli > Well, its a little wierd, looks like something is broken compilation wise in the recovery code, or we trampled on ourselves. We passed a null pointer in xfs_next_bit which is why it blew up, the caller does have a way of doing this: unsigned int *data_map = NULL; unsigned int map_size = 0; switch (buf_f->blf_type) { case XFS_LI_BUF: data_map = buf_f->blf_data_map; map_size = buf_f->blf_map_size; break; case XFS_LI_6_1_BUF: case XFS_LI_5_3_BUF: obuf_f = (xfs_buf_log_format_v1_t*)buf_f; data_map = obuf_f->blf_data_map; map_size = obuf_f->blf_map_size; break; } ...... bit = xfs_next_bit(data_map, map_size, bit); We definitely did not hit any of the expected cases in the switch statement and we passed null into xfs_next_bit(). However, the only caller of this function does a check of the same data structure and will fail recovery if it does not get one of the recognized flags. So unless some of the code in between the two stamped on the memory in the mean time it looks like a compilation bug. Is this repeatable? We could probably come up with some extra checks in here to narrow it down. It might also be worth doing an xfs_logprint -t -i -b /dev/xxx if this happens again and sending the output. This would at least determine if what was on the disk was correct. Nathan, any other ideas? Steve From owner-linux-xfs@oss.sgi.com Fri Mar 12 19:48:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 12 Mar 2004 19:48:20 -0800 (PST) Received: from holomorphy.com (mail@holomorphy.com [207.189.100.168]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2D3mIKO023237 for ; Fri, 12 Mar 2004 19:48:18 -0800 Received: from wli by holomorphy.com with local (Exim 3.36 #1 (Debian)) id 1B208E-00078C-00; Fri, 12 Mar 2004 19:48:14 -0800 Date: Fri, 12 Mar 2004 19:48:14 -0800 From: William Lee Irwin III To: Steve Lord Cc: linux-xfs@oss.sgi.com, Nathan Scott Subject: Re: xfs recovery oops in 2.6.4-mm1 Message-ID: <20040313034814.GY655@holomorphy.com> References: <20040312100025.GP655@holomorphy.com> <4051D517.4070005@xfs.org> <20040312233153.GT655@holomorphy.com> <4052834B.5010208@xfs.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4052834B.5010208@xfs.org> Organization: The Domain of Holomorphy User-Agent: Mutt/1.5.5.1+cvs20040105i Content-Transfer-Encoding: 8bit X-archive-position: 2444 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wli@holomorphy.com Precedence: bulk X-list: linux-xfs Content-Length: 1500 Lines: 32 On Fri, Mar 12, 2004 at 09:43:07PM -0600, Steve Lord wrote: > Well, its a little wierd, looks like something is broken compilation > wise in the recovery code, or we trampled on ourselves. > We passed a null pointer in xfs_next_bit which is why it blew up, > the caller does have a way of doing this: [...] > We definitely did not hit any of the expected cases in the switch > statement and we passed null into xfs_next_bit(). > However, the only caller of this function does a check of the same > data structure and will fail recovery if it does not get one of the > recognized flags. > So unless some of the code in between the two stamped on the memory > in the mean time it looks like a compilation bug. > Is this repeatable? We could probably come up with some extra checks in > here to narrow it down. It might also be worth doing an > xfs_logprint -t -i -b /dev/xxx > if this happens again and sending the output. This would at least > determine if what was on the disk was correct. > Nathan, any other ideas? A compiler bug isn't out of the question, though I don't see signs of it in the disassembly (doesn't mean it's not happening). I have to brew up some way to corrupt the fs and get it to try to recover via mounting it to reproduce, which doesn't happen for ordinary pulling the plug -type of affairs. It did recur 3 times when I once I got it corrupted properly, so it's mostly a question of doing that. I think it's related to heavy io going on when the plug is pulled. -- wli From owner-linux-xfs@oss.sgi.com Sun Mar 14 06:00:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Mar 2004 06:01:03 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2EE0aKO006915 for ; Sun, 14 Mar 2004 06:00:37 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1B2WAL-0002KB-2n; Sun, 14 Mar 2004 14:00:33 +0000 Date: Sun, 14 Mar 2004 14:00:32 +0000 From: Christoph Hellwig To: Chris Mason , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [PATCH] lockfs patch for 2.6 Message-ID: <20040314140032.A8901@infradead.org> Mail-Followup-To: Christoph Hellwig , Chris Mason , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <1078867885.25075.1458.camel@watt.suse.com> <20040313131447.A25900@infradead.org> <1079191213.4187.243.camel@watt.suse.com> <20040313163346.A27004@infradead.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040313163346.A27004@infradead.org>; from hch@infradead.org on Sat, Mar 13, 2004 at 04:33:46PM +0000 Content-Transfer-Encoding: 8bit X-archive-position: 2445 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 16422 Lines: 605 On Sat, Mar 13, 2004 at 04:33:46PM +0000, Christoph Hellwig wrote: > Here's the reworked patch I have, ignoring dm but converting the xfs-internal > interfaces that do freezing. But without an interface change we still need > to do all the flushing a second time inside XFS which I absoutely dislike. > > Let me think about how to do this nicer. Okay, here's a new patch that basically moves all the XFS freezing infrastructure to the VFS, leavin only writing of the log record and some transaction count handing inside XFS. I've given it some heavy testing with xfs_freeze, dm is still not updated. P.S. this patch now kills 16 lines of kernel code summarized :) --- 1.155/fs/block_dev.c Fri Mar 12 10:33:01 2004 +++ edited/fs/block_dev.c Sat Mar 13 15:28:49 2004 @@ -251,6 +251,7 @@ { memset(bdev, 0, sizeof(*bdev)); sema_init(&bdev->bd_sem, 1); + sema_init(&bdev->bd_mount_sem, 1); INIT_LIST_HEAD(&bdev->bd_inodes); INIT_LIST_HEAD(&bdev->bd_list); inode_init_once(&ei->vfs_inode); ===== fs/buffer.c 1.224 vs edited ===== --- 1.224/fs/buffer.c Sun Mar 7 08:16:11 2004 +++ edited/fs/buffer.c Sun Mar 14 15:37:00 2004 @@ -260,6 +260,69 @@ } /* + * triggered by the device mapper code to lock a filesystem and force + * it into a consistent state. + * + * This takes the block device bd_mount_sem to make sure no new mounts + * happen on bdev until unlockfs is called. If a super is found on this + * block device, we hould a read lock on the s->s_umount sem to make sure + * nobody unmounts until the snapshot creation is done + */ +struct super_block *freeze_bdev(struct block_device *bdev) +{ + struct super_block *sb; + + down(&bdev->bd_mount_sem); + sb = get_super(bdev); + if (sb && !(sb->s_flags & MS_RDONLY)) { + sb->s_frozen = SB_FREEZE_WRITE; + wmb(); + + sync_inodes_sb(sb, 0); + DQUOT_SYNC(sb); + + sb->s_frozen = SB_FREEZE_TRANS; + wmb(); + + lock_super(sb); + if (sb->s_dirt && sb->s_op->write_super) + sb->s_op->write_super(sb); + unlock_super(sb); + + if (sb->s_op->sync_fs) + sb->s_op->sync_fs(sb, 1); + + sync_blockdev(sb->s_bdev); + sync_inodes_sb(sb, 1); + sync_blockdev(sb->s_bdev); + + if (sb->s_op->write_super_lockfs) + sb->s_op->write_super_lockfs(sb); + } + + sync_blockdev(bdev); + return sb; /* thaw_bdev releases s->s_umount and bd_mount_sem */ +} +EXPORT_SYMBOL(freeze_bdev); + +void thaw_bdev(struct block_device *bdev, struct super_block *sb) +{ + if (sb) { + BUG_ON(sb->s_bdev != bdev); + + if (sb->s_op->unlockfs) + sb->s_op->unlockfs(sb); + sb->s_frozen = SB_UNFROZEN; + wmb(); + wake_up(&sb->s_wait_unfrozen); + drop_super(sb); + } + + up(&bdev->bd_mount_sem); +} +EXPORT_SYMBOL(thaw_bdev); + +/* * sync everything. Start out by waking pdflush, because that writes back * all queues in parallel. */ ===== fs/super.c 1.115 vs edited ===== --- 1.115/fs/super.c Fri Mar 12 10:30:24 2004 +++ edited/fs/super.c Sun Mar 14 14:24:56 2004 @@ -77,6 +77,7 @@ sema_init(&s->s_dquot.dqio_sem, 1); sema_init(&s->s_dquot.dqonoff_sem, 1); init_rwsem(&s->s_dquot.dqptr_sem); + init_waitqueue_head(&s->s_wait_unfrozen); s->s_maxbytes = MAX_NON_LFS; s->dq_op = sb_dquot_ops; s->s_qcop = sb_quotactl_ops; @@ -621,7 +622,14 @@ if (IS_ERR(bdev)) return (struct super_block *)bdev; + /* + * once the super is inserted into the list by sget, s_umount + * will protect the lockfs code from trying to start a snapshot + * while we are mounting + */ + down(&bdev->bd_mount_sem); s = sget(fs_type, test_bdev_super, set_bdev_super, bdev); + up(&bdev->bd_mount_sem); if (IS_ERR(s)) goto out; ===== fs/xfs/xfs_fsops.c 1.11 vs edited ===== --- 1.11/fs/xfs/xfs_fsops.c Fri Feb 27 07:28:05 2004 +++ edited/fs/xfs/xfs_fsops.c Sun Mar 14 14:03:01 2004 @@ -582,63 +582,25 @@ } int -xfs_fs_freeze( - xfs_mount_t *mp) -{ - vfs_t *vfsp; - /*REFERENCED*/ - int error; - - vfsp = XFS_MTOVFS(mp); - - /* Stop new writers */ - xfs_start_freeze(mp, XFS_FREEZE_WRITE); - - /* Flush the refcache */ - xfs_refcache_purge_mp(mp); - - /* Flush delalloc and delwri data */ - VFS_SYNC(vfsp, SYNC_DELWRI|SYNC_WAIT, NULL, error); - - /* Pause transaction subsystem */ - xfs_start_freeze(mp, XFS_FREEZE_TRANS); - - /* Flush any remaining inodes into buffers */ - VFS_SYNC(vfsp, SYNC_ATTR|SYNC_WAIT, NULL, error); - - /* Push all buffers out to disk */ - xfs_binval(mp->m_ddev_targp); - if (mp->m_rtdev_targp) { - xfs_binval(mp->m_rtdev_targp); - } - - /* Push the superblock and write an unmount record */ - xfs_log_unmount_write(mp); - xfs_unmountfs_writesb(mp); - - return 0; -} - -int -xfs_fs_thaw( - xfs_mount_t *mp) -{ - xfs_finish_freeze(mp); - return 0; -} - -int xfs_fs_goingdown( xfs_mount_t *mp, __uint32_t inflags) { - switch (inflags) - { - case XFS_FSOP_GOING_FLAGS_DEFAULT: - xfs_fs_freeze(mp); - xfs_force_shutdown(mp, XFS_FORCE_UMOUNT); - xfs_fs_thaw(mp); + if (!capable(CAP_SYS_ADMIN)) + return -EPERM; + + switch (inflags) { + case XFS_FSOP_GOING_FLAGS_DEFAULT: { + struct vfs *vfsp = XFS_MTOVFS(mp); + struct super_block *sb = freeze_bdev(vfsp->vfs_super->s_bdev); + + if (sb) { + xfs_force_shutdown(mp, XFS_FORCE_UMOUNT); + thaw_bdev(sb->s_bdev, sb); + } + break; + } case XFS_FSOP_GOING_FLAGS_LOGFLUSH: xfs_force_shutdown(mp, XFS_FORCE_UMOUNT); break; ===== fs/xfs/xfs_fsops.h 1.3 vs edited ===== --- 1.3/fs/xfs/xfs_fsops.h Fri Feb 27 07:28:05 2004 +++ edited/fs/xfs/xfs_fsops.h Sun Mar 14 14:03:33 2004 @@ -60,14 +60,6 @@ xfs_fsop_resblks_t *outval); int -xfs_fs_freeze( - xfs_mount_t *mp); - -int -xfs_fs_thaw( - xfs_mount_t *mp); - -int xfs_fs_goingdown( xfs_mount_t *mp, __uint32_t inflags); ===== fs/xfs/xfs_log.c 1.34 vs edited ===== --- 1.34/fs/xfs/xfs_log.c Sat Mar 6 04:16:30 2004 +++ edited/fs/xfs/xfs_log.c Sun Mar 14 13:59:50 2004 @@ -820,7 +820,7 @@ xlog_t *log = mp->m_log; vfs_t *vfsp = XFS_MTOVFS(mp); - if (mp->m_frozen || XFS_FORCED_SHUTDOWN(mp) || + if (vfsp->vfs_super->s_frozen || XFS_FORCED_SHUTDOWN(mp) || (vfsp->vfs_flag & VFS_RDONLY)) return 0; ===== fs/xfs/xfs_mount.c 1.41 vs edited ===== --- 1.41/fs/xfs/xfs_mount.c Fri Feb 27 07:54:47 2004 +++ edited/fs/xfs/xfs_mount.c Sun Mar 14 14:01:45 2004 @@ -139,9 +139,6 @@ */ xfs_trans_ail_init(mp); - /* Init freeze sync structures */ - spinlock_init(&mp->m_freeze_lock, "xfs_freeze"); - init_sv(&mp->m_wait_unfreeze, SV_DEFAULT, "xfs_freeze", 0); atomic_set(&mp->m_active_trans, 0); return mp; @@ -191,8 +188,6 @@ VFS_REMOVEBHV(vfsp, &mp->m_bhv); } - spinlock_destroy(&mp->m_freeze_lock); - sv_destroy(&mp->m_wait_unfreeze); kmem_free(mp, sizeof(xfs_mount_t)); } @@ -1584,60 +1579,4 @@ } xfs_mod_sb(tp, fields); xfs_trans_commit(tp, 0, NULL); -} - -/* Functions to lock access out of the filesystem for forced - * shutdown or snapshot. - */ - -void -xfs_start_freeze( - xfs_mount_t *mp, - int level) -{ - unsigned long s = mutex_spinlock(&mp->m_freeze_lock); - - mp->m_frozen = level; - mutex_spinunlock(&mp->m_freeze_lock, s); - - if (level == XFS_FREEZE_TRANS) { - while (atomic_read(&mp->m_active_trans) > 0) - delay(100); - } -} - -void -xfs_finish_freeze( - xfs_mount_t *mp) -{ - unsigned long s = mutex_spinlock(&mp->m_freeze_lock); - - if (mp->m_frozen) { - mp->m_frozen = 0; - sv_broadcast(&mp->m_wait_unfreeze); - } - - mutex_spinunlock(&mp->m_freeze_lock, s); -} - -void -xfs_check_frozen( - xfs_mount_t *mp, - bhv_desc_t *bdp, - int level) -{ - unsigned long s; - - if (mp->m_frozen) { - s = mutex_spinlock(&mp->m_freeze_lock); - - if (mp->m_frozen < level) { - mutex_spinunlock(&mp->m_freeze_lock, s); - } else { - sv_wait(&mp->m_wait_unfreeze, 0, &mp->m_freeze_lock, s); - } - } - - if (level == XFS_FREEZE_TRANS) - atomic_inc(&mp->m_active_trans); } ===== fs/xfs/xfs_mount.h 1.25 vs edited ===== --- 1.25/fs/xfs/xfs_mount.h Wed Mar 3 05:52:57 2004 +++ edited/fs/xfs/xfs_mount.h Sun Mar 14 14:02:01 2004 @@ -379,10 +379,6 @@ struct xfs_dmops m_dm_ops; /* vector of DMI ops */ struct xfs_qmops m_qm_ops; /* vector of XQM ops */ struct xfs_ioops m_io_ops; /* vector of I/O ops */ - lock_t m_freeze_lock; /* Lock for m_frozen */ - uint m_frozen; /* FS frozen for shutdown or - * snapshot */ - sv_t m_wait_unfreeze;/* waiting to unfreeze */ atomic_t m_active_trans; /* number trans frozen */ } xfs_mount_t; @@ -557,16 +553,6 @@ extern void xfs_initialize_perag(xfs_mount_t *, int); extern void xfs_xlatesb(void *, struct xfs_sb *, int, xfs_arch_t, __int64_t); - -/* - * Flags for freeze operations. - */ -#define XFS_FREEZE_WRITE 1 -#define XFS_FREEZE_TRANS 2 - -extern void xfs_start_freeze(xfs_mount_t *, int); -extern void xfs_finish_freeze(xfs_mount_t *); -extern void xfs_check_frozen(xfs_mount_t *, bhv_desc_t *, int); extern struct vfsops xfs_vfsops; extern struct vnodeops xfs_vnodeops; ===== fs/xfs/xfs_trans.c 1.14 vs edited ===== --- 1.14/fs/xfs/xfs_trans.c Fri Jan 9 00:18:09 2004 +++ edited/fs/xfs/xfs_trans.c Sun Mar 14 14:01:41 2004 @@ -131,7 +131,9 @@ xfs_mount_t *mp, uint type) { - xfs_check_frozen(mp, NULL, XFS_FREEZE_TRANS); + vfs_check_frozen(XFS_MTOVFS(mp)->vfs_super, SB_FREEZE_TRANS); + atomic_inc(&mp->m_active_trans); + return (_xfs_trans_alloc(mp, type)); } ===== fs/xfs/xfs_vfsops.c 1.57 vs edited ===== --- 1.57/fs/xfs/xfs_vfsops.c Wed Mar 3 05:52:58 2004 +++ edited/fs/xfs/xfs_vfsops.c Sun Mar 14 14:42:21 2004 @@ -1544,6 +1544,11 @@ } } + if (XFS_MTOVFS(mp)->vfs_super->s_frozen == SB_FREEZE_TRANS) { + while (atomic_read(&mp->m_active_trans) > 0) + delay(100); + } + return XFS_ERROR(last_error); } @@ -1853,6 +1858,17 @@ return 0; } +STATIC void +xfs_freeze( + bhv_desc_t *bdp) +{ + xfs_mount_t *mp = XFS_BHVTOM(bdp); + + /* Push the superblock and write an unmount record */ + xfs_log_unmount_write(mp); + xfs_unmountfs_writesb(mp); +} + vfsops_t xfs_vfsops = { BHV_IDENTITY_INIT(VFS_BHV_XFS,VFS_POSITION_XFS), @@ -1869,4 +1885,5 @@ .vfs_quotactl = (vfs_quotactl_t)fs_nosys, .vfs_init_vnode = xfs_initialize_vnode, .vfs_force_shutdown = xfs_do_force_shutdown, + .vfs_freeze = xfs_freeze, }; ===== fs/xfs/linux/xfs_ioctl.c 1.21 vs edited ===== --- 1.21/fs/xfs/linux/xfs_ioctl.c Fri Feb 27 07:28:05 2004 +++ edited/fs/xfs/linux/xfs_ioctl.c Sat Mar 13 18:23:23 2004 @@ -825,13 +825,14 @@ case XFS_IOC_FREEZE: if (!capable(CAP_SYS_ADMIN)) return -EPERM; - xfs_fs_freeze(mp); + + freeze_bdev(inode->i_sb->s_bdev); return 0; case XFS_IOC_THAW: if (!capable(CAP_SYS_ADMIN)) return -EPERM; - xfs_fs_thaw(mp); + thaw_bdev(inode->i_sb->s_bdev, inode->i_sb); return 0; case XFS_IOC_GOINGDOWN: { ===== fs/xfs/linux/xfs_lrw.c 1.40 vs edited ===== --- 1.40/fs/xfs/linux/xfs_lrw.c Wed Mar 3 05:52:57 2004 +++ edited/fs/xfs/linux/xfs_lrw.c Sun Mar 14 14:47:00 2004 @@ -682,8 +682,6 @@ io = &xip->i_iocore; mp = io->io_mount; - xfs_check_frozen(mp, bdp, XFS_FREEZE_WRITE); - if (XFS_FORCED_SHUTDOWN(mp)) { return -EIO; } ===== fs/xfs/linux/xfs_super.c 1.70 vs edited ===== --- 1.70/fs/xfs/linux/xfs_super.c Sat Mar 6 04:46:51 2004 +++ edited/fs/xfs/linux/xfs_super.c Sun Mar 14 14:43:46 2004 @@ -589,28 +589,7 @@ linvfs_freeze_fs( struct super_block *sb) { - vfs_t *vfsp = LINVFS_GET_VFS(sb); - vnode_t *vp; - int error; - - if (sb->s_flags & MS_RDONLY) - return; - VFS_ROOT(vfsp, &vp, error); - VOP_IOCTL(vp, LINVFS_GET_IP(vp), NULL, 0, XFS_IOC_FREEZE, 0, error); - VN_RELE(vp); -} - -STATIC void -linvfs_unfreeze_fs( - struct super_block *sb) -{ - vfs_t *vfsp = LINVFS_GET_VFS(sb); - vnode_t *vp; - int error; - - VFS_ROOT(vfsp, &vp, error); - VOP_IOCTL(vp, LINVFS_GET_IP(vp), NULL, 0, XFS_IOC_THAW, 0, error); - VN_RELE(vp); + VFS_FREEZE(LINVFS_GET_VFS(sb)); } STATIC struct dentry * @@ -850,7 +829,6 @@ .write_super = linvfs_write_super, .sync_fs = linvfs_sync_super, .write_super_lockfs = linvfs_freeze_fs, - .unlockfs = linvfs_unfreeze_fs, .statfs = linvfs_statfs, .remount_fs = linvfs_remount, .show_options = linvfs_show_options, ===== fs/xfs/linux/xfs_vfs.c 1.11 vs edited ===== --- 1.11/fs/xfs/linux/xfs_vfs.c Wed Mar 3 05:52:57 2004 +++ edited/fs/xfs/linux/xfs_vfs.c Sun Mar 14 14:43:15 2004 @@ -230,6 +230,18 @@ ((*bhvtovfsops(next)->vfs_force_shutdown)(next, fl, file, line)); } +void +vfs_freeze( + struct bhv_desc *bdp) +{ + struct bhv_desc *next = bdp; + + ASSERT(next); + while (! (bhvtovfsops(next))->vfs_freeze) + next = BHV_NEXT(next); + ((*bhvtovfsops(next)->vfs_freeze)(next)); +} + vfs_t * vfs_allocate( void ) { ===== fs/xfs/linux/xfs_vfs.h 1.18 vs edited ===== --- 1.18/fs/xfs/linux/xfs_vfs.h Fri Jan 9 06:59:58 2004 +++ edited/fs/xfs/linux/xfs_vfs.h Sun Mar 14 14:43:07 2004 @@ -112,6 +112,7 @@ typedef void (*vfs_init_vnode_t)(bhv_desc_t *, struct vnode *, bhv_desc_t *, int); typedef void (*vfs_force_shutdown_t)(bhv_desc_t *, int, char *, int); +typedef void (*vfs_freeze_t)(bhv_desc_t *); typedef struct vfsops { bhv_position_t vf_position; /* behavior chain position */ @@ -128,6 +129,7 @@ vfs_quotactl_t vfs_quotactl; /* disk quota */ vfs_init_vnode_t vfs_init_vnode; /* initialize a new vnode */ vfs_force_shutdown_t vfs_force_shutdown; /* crash and burn */ + vfs_freeze_t vfs_freeze; /* freeze fs for snapshot */ } vfsops_t; /* @@ -147,6 +149,7 @@ #define VFS_QUOTACTL(v, c,id,p, rv) ((rv) = vfs_quotactl(VHEAD(v), c,id,p)) #define VFS_INIT_VNODE(v, vp,b,ul) ( vfs_init_vnode(VHEAD(v), vp,b,ul) ) #define VFS_FORCE_SHUTDOWN(v, fl,f,l) ( vfs_force_shutdown(VHEAD(v), fl,f,l) ) +#define VFS_FREEZE(v) ( vfs_freeze(VHEAD(v)) ) /* * PVFS's. Operates on behavior descriptor pointers. @@ -164,6 +167,7 @@ #define PVFS_QUOTACTL(b, c,id,p, rv) ((rv) = vfs_quotactl(b, c,id,p)) #define PVFS_INIT_VNODE(b, vp,b2,ul) ( vfs_init_vnode(b, vp,b2,ul) ) #define PVFS_FORCE_SHUTDOWN(b, fl,f,l) ( vfs_force_shutdown(b, fl,f,l) ) +#define PVFS_FREEZE(b) ( vfs_freeze(b) ) extern int vfs_mount(bhv_desc_t *, struct xfs_mount_args *, struct cred *); extern int vfs_parseargs(bhv_desc_t *, char *, struct xfs_mount_args *, int); @@ -178,6 +182,7 @@ extern int vfs_quotactl(bhv_desc_t *, int, int, caddr_t); extern void vfs_init_vnode(bhv_desc_t *, struct vnode *, bhv_desc_t *, int); extern void vfs_force_shutdown(bhv_desc_t *, int, char *, int); +extern void vfs_freeze(bhv_desc_t *); typedef struct bhv_vfsops { struct vfsops bhv_common; ===== include/linux/buffer_head.h 1.46 vs edited ===== --- 1.46/include/linux/buffer_head.h Tue Jan 20 00:38:11 2004 +++ edited/include/linux/buffer_head.h Sat Mar 13 15:35:32 2004 @@ -164,6 +164,8 @@ wait_queue_head_t *bh_waitq_head(struct buffer_head *bh); void wake_up_buffer(struct buffer_head *bh); int fsync_bdev(struct block_device *); +struct super_block *freeze_bdev(struct block_device *); +void thaw_bdev(struct block_device *, struct super_block *); int fsync_super(struct super_block *); int fsync_no_super(struct block_device *); struct buffer_head *__find_get_block(struct block_device *, sector_t, int); ===== include/linux/fs.h 1.290 vs edited ===== --- 1.290/include/linux/fs.h Fri Mar 12 10:32:59 2004 +++ edited/include/linux/fs.h Sun Mar 14 14:08:14 2004 @@ -344,6 +344,7 @@ struct inode * bd_inode; /* will die */ int bd_openers; struct semaphore bd_sem; /* open/close mutex */ + struct semaphore bd_mount_sem; /* mount mutex */ struct list_head bd_inodes; void * bd_holder; int bd_holders; @@ -712,6 +713,9 @@ struct list_head s_instances; struct quota_info s_dquot; /* Diskquota specific options */ + int s_frozen; + wait_queue_head_t s_wait_unfrozen; + char s_id[32]; /* Informational name */ struct kobject kobj; /* anchor for sysfs */ @@ -723,6 +727,18 @@ */ struct semaphore s_vfs_rename_sem; /* Kludge */ }; + +/* + * Snapshotting support. + */ +enum { + SB_UNFROZEN = 0, + SB_FREEZE_WRITE = 1, + SB_FREEZE_TRANS = 2, +}; + +#define vfs_check_frozen(sb, level) \ + wait_event((sb)->s_wait_unfrozen, ((sb)->s_frozen < (level))) /* * Superblock locking. ===== mm/filemap.c 1.225 vs edited ===== --- 1.225/mm/filemap.c Mon Mar 8 15:21:17 2004 +++ edited/mm/filemap.c Sun Mar 14 14:16:40 2004 @@ -1746,6 +1746,8 @@ unsigned long seg; char __user *buf; + vfs_check_frozen(inode->i_sb, SB_FREEZE_WRITE); + ocount = 0; for (seg = 0; seg < nr_segs; seg++) { const struct iovec *iv = &iov[seg]; From owner-linux-xfs@oss.sgi.com Sun Mar 14 08:05:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Mar 2004 08:05:28 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2EG5DKO010088 for ; Sun, 14 Mar 2004 08:05:14 -0800 Received: from extimap.suse.de (extimap.suse.de [195.135.220.6]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id B29CC2EF7D0 for ; Sun, 14 Mar 2004 16:21:16 +0100 (CET) Received: by extimap.suse.de (Postfix, from userid 65534) id 5FF6F86981; Sun, 14 Mar 2004 16:21:11 +0100 (CET) Received: from watt.suse.com (roc-24-169-15-66.rochester.rr.com [24.169.15.66]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by extimap.suse.de (Postfix) with ESMTP id 8E4FB86942; Sun, 14 Mar 2004 16:20:54 +0100 (CET) Subject: Re: [PATCH] lockfs patch for 2.6 From: Chris Mason To: Christoph Hellwig Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com In-Reply-To: <20040314140032.A8901@infradead.org> References: <1078867885.25075.1458.camel@watt.suse.com> <20040313131447.A25900@infradead.org> <1079191213.4187.243.camel@watt.suse.com> <20040313163346.A27004@infradead.org> <20040314140032.A8901@infradead.org> Content-type: text/plain Message-Id: <1079277810.4183.249.camel@watt.suse.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 14 Mar 2004 10:23:31 -0500 Content-Transfer-Encoding: 8bit X-archive-position: 2446 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mason@suse.com Precedence: bulk X-list: linux-xfs Content-Length: 800 Lines: 22 On Sun, 2004-03-14 at 09:00, Christoph Hellwig wrote: > On Sat, Mar 13, 2004 at 04:33:46PM +0000, Christoph Hellwig wrote: > > Here's the reworked patch I have, ignoring dm but converting the xfs-internal > > interfaces that do freezing. But without an interface change we still need > > to do all the flushing a second time inside XFS which I absoutely dislike. > > > > Let me think about how to do this nicer. > > Okay, here's a new patch that basically moves all the XFS freezing > infrastructure to the VFS, leavin only writing of the log record and some > transaction count handing inside XFS. > > I've given it some heavy testing with xfs_freeze, dm is still not updated. > > P.S. this patch now kills 16 lines of kernel code summarized :) > It looks good, I'll give it a try. -chris From owner-linux-xfs@oss.sgi.com Sun Mar 14 10:44:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Mar 2004 10:44:50 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2EIilKO023291 for ; Sun, 14 Mar 2004 10:44:47 -0800 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i2EIiXE12773; Sun, 14 Mar 2004 10:44:33 -0800 Date: Sun, 14 Mar 2004 10:44:39 -0800 From: Andrew Morton To: Christoph Hellwig Cc: mason@suse.com, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [PATCH] lockfs patch for 2.6 Message-Id: <20040314104439.7c381a09.akpm@osdl.org> In-Reply-To: <20040314140032.A8901@infradead.org> References: <1078867885.25075.1458.camel@watt.suse.com> <20040313131447.A25900@infradead.org> <1079191213.4187.243.camel@watt.suse.com> <20040313163346.A27004@infradead.org> <20040314140032.A8901@infradead.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2447 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: linux-xfs Content-Length: 493 Lines: 12 Christoph Hellwig wrote: > > + * This takes the block device bd_mount_sem to make sure no new mounts > + * happen on bdev until unlockfs is called. If a super is found on this > + * block device, we hould a read lock on the s->s_umount sem to make sure > + * nobody unmounts until the snapshot creation is done > + */ > +struct super_block *freeze_bdev(struct block_device *bdev) I think you do need s_umount, as the comments say. But this patch doesn't touch it. From owner-linux-xfs@oss.sgi.com Sun Mar 14 10:53:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Mar 2004 10:53:04 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2EIqxKO023778 for ; Sun, 14 Mar 2004 10:53:00 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1B2ajG-0002rJ-BP; Sun, 14 Mar 2004 18:52:54 +0000 Date: Sun, 14 Mar 2004 18:52:54 +0000 From: Christoph Hellwig To: Andrew Morton Cc: mason@suse.com, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [PATCH] lockfs patch for 2.6 Message-ID: <20040314185254.A10989@infradead.org> Mail-Followup-To: Christoph Hellwig , Andrew Morton , mason@suse.com, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <1078867885.25075.1458.camel@watt.suse.com> <20040313131447.A25900@infradead.org> <1079191213.4187.243.camel@watt.suse.com> <20040313163346.A27004@infradead.org> <20040314140032.A8901@infradead.org> <20040314104439.7c381a09.akpm@osdl.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040314104439.7c381a09.akpm@osdl.org>; from akpm@osdl.org on Sun, Mar 14, 2004 at 10:44:39AM -0800 Content-Transfer-Encoding: 8bit X-archive-position: 2448 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 555 Lines: 13 On Sun, Mar 14, 2004 at 10:44:39AM -0800, Andrew Morton wrote: > > + * This takes the block device bd_mount_sem to make sure no new mounts > > + * happen on bdev until unlockfs is called. If a super is found on this > > + * block device, we hould a read lock on the s->s_umount sem to make sure > > + * nobody unmounts until the snapshot creation is done > > + */ > > +struct super_block *freeze_bdev(struct block_device *bdev) > > I think you do need s_umount, as the comments say. But this patch doesn't > touch it. get_super takes it for us. From owner-linux-xfs@oss.sgi.com Sun Mar 14 11:25:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Mar 2004 11:25:20 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2EJP7KO025099 for ; Sun, 14 Mar 2004 11:25:08 -0800 Received: from extimap.suse.de (extimap.suse.de [195.135.220.6]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 4F0782F2F2A for ; Sun, 14 Mar 2004 19:54:17 +0100 (CET) Received: by extimap.suse.de (Postfix, from userid 65534) id 18FAB86A5C; Sun, 14 Mar 2004 19:54:07 +0100 (CET) Received: from watt.suse.com (roc-24-169-15-66.rochester.rr.com [24.169.15.66]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by extimap.suse.de (Postfix) with ESMTP id 9F38F85106; Sun, 14 Mar 2004 19:53:54 +0100 (CET) Subject: Re: [PATCH] lockfs patch for 2.6 From: Chris Mason To: Andrew Morton Cc: Christoph Hellwig , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com In-Reply-To: <20040314104439.7c381a09.akpm@osdl.org> References: <1078867885.25075.1458.camel@watt.suse.com> <20040313131447.A25900@infradead.org> <1079191213.4187.243.camel@watt.suse.com> <20040313163346.A27004@infradead.org> <20040314140032.A8901@infradead.org> <20040314104439.7c381a09.akpm@osdl.org> Content-type: text/plain Message-Id: <1079290590.4183.258.camel@watt.suse.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 14 Mar 2004 13:56:30 -0500 Content-Transfer-Encoding: 8bit X-archive-position: 2449 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mason@suse.com Precedence: bulk X-list: linux-xfs Content-Length: 613 Lines: 18 On Sun, 2004-03-14 at 13:44, Andrew Morton wrote: > Christoph Hellwig wrote: > > > > + * This takes the block device bd_mount_sem to make sure no new mounts > > + * happen on bdev until unlockfs is called. If a super is found on this > > + * block device, we hould a read lock on the s->s_umount sem to make sure > > + * nobody unmounts until the snapshot creation is done > > + */ > > +struct super_block *freeze_bdev(struct block_device *bdev) > > I think you do need s_umount, as the comments say. But this patch doesn't > touch it. get_super gives us a read lock on it. -chris From owner-linux-xfs@oss.sgi.com Sun Mar 14 15:31:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Mar 2004 15:31:52 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2ENVmKO001087 for ; Sun, 14 Mar 2004 15:31:48 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2F1XD4d032439 for ; Sun, 14 Mar 2004 17:33:14 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA18560; Mon, 15 Mar 2004 10:31:38 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2ENVWFx340797; Mon, 15 Mar 2004 10:31:34 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i2ENUuGN000802; Mon, 15 Mar 2004 10:31:05 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i2ENUslo000800; Mon, 15 Mar 2004 10:30:54 +1100 Date: Mon, 15 Mar 2004 10:30:54 +1100 From: Nathan Scott To: William Lee Irwin III , Steve Lord , tes@sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: xfs recovery oops in 2.6.4-mm1 Message-ID: <20040314233054.GA643@frodo> References: <20040312100025.GP655@holomorphy.com> <4051D517.4070005@xfs.org> <20040312233153.GT655@holomorphy.com> <4052834B.5010208@xfs.org> Mime-Version: 1.0 Content-type: text/plain Content-Disposition: inline In-Reply-To: <4052834B.5010208@xfs.org> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2450 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3752 Lines: 100 Hi guys, On Fri, Mar 12, 2004 at 09:19:51AM -0600, Steve Lord wrote: > Have you successfully used xfs on this box with older kernels, or is > this a new filesystem? Was this the first mount under 2.6.4-mm1? This would be useful to know. On Fri, Mar 12, 2004 at 09:43:07PM -0600, Steve Lord wrote: > > On Fri, Mar 12, 2004 at 09:19:51AM -0600, Steve Lord wrote: > > > >>I see this is a sparc, any chance you could provide disassembly of the > >>xfs_next_bit function. I wonder if it is playing up on this processor, > >>it makes use of ffs and we have had some architecture issues with it > >>before. > > Well, its a little wierd, looks like something is broken compilation > wise in the recovery code, or we trampled on ourselves. > > We passed a null pointer in xfs_next_bit which is why it blew up, > the caller does have a way of doing this: > > unsigned int *data_map = NULL; > unsigned int map_size = 0; > > switch (buf_f->blf_type) { > case XFS_LI_BUF: > data_map = buf_f->blf_data_map; > map_size = buf_f->blf_map_size; > break; > case XFS_LI_6_1_BUF: > case XFS_LI_5_3_BUF: > obuf_f = (xfs_buf_log_format_v1_t*)buf_f; > data_map = obuf_f->blf_data_map; > map_size = obuf_f->blf_map_size; > break; > } > > ...... > > bit = xfs_next_bit(data_map, map_size, bit); > > We definitely did not hit any of the expected cases in the switch > statement and we passed null into xfs_next_bit(). Hmmm. Should be impossible, given the caller, which does suggest a compiler issue I agree. > However, the only caller of this function does a check of the same > data structure and will fail recovery if it does not get one of the > recognized flags. > > So unless some of the code in between the two stamped on the memory > in the mean time it looks like a compilation bug. Theres not much code inbetween for something to go wrong, and nothing I can see that explicitly futzes with buf_f where the null pointer would be originating. > Is this repeatable? We could probably come up with some extra checks in > here to narrow it down. It might also be worth doing an > > xfs_logprint -t -i -b /dev/xxx > > if this happens again and sending the output. This would at least > determine if what was on the disk was correct. > > Nathan, any other ideas? Yeah, above dump would be useful; ideally we need to find a reproducible test case too - this might help there... On Fri, Mar 12, 2004 at 07:48:14PM -0800, William Lee Irwin III wrote: > On Fri, Mar 12, 2004 at 09:43:07PM -0600, Steve Lord wrote: > I have to brew up some way to corrupt the fs and get it to try to > recover via mounting it to reproduce, which doesn't happen for ordinary > pulling the plug -type of affairs. It did recur 3 times when I once I > got it corrupted properly, so it's mostly a question of doing that. I > think it's related to heavy io going on when the plug is pulled. Attached is a test program thats been used to exercise log recovery in a more user-friendly fashion. It uses the xfs forced-shutdown mode to get a dirty log without having to pull the plug. So, generate traffic, shutdown, unmount, & then the next mount will do log recovery. If you find the right traffic to generate a reproducible failure, diagnosing this becomes a whole lot easier. There's other tools for generating all manner of different types of traffic in the xfstests directory in the xfs userspace cvs too - fsstress is a good one for generating lots of metadata operations. cheers. -- Nathan -- Binary/unsupported file stripped by Ecartis -- -- Type: text/x-csrc From owner-linux-xfs@oss.sgi.com Sun Mar 14 15:36:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Mar 2004 15:36:22 -0800 (PST) Received: from holomorphy.com (mail@holomorphy.com [207.189.100.168]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2ENaIKO001592 for ; Sun, 14 Mar 2004 15:36:19 -0800 Received: from wli by holomorphy.com with local (Exim 3.36 #1 (Debian)) id 1B2f9I-0004be-00; Sun, 14 Mar 2004 15:36:04 -0800 Date: Sun, 14 Mar 2004 15:36:04 -0800 From: William Lee Irwin III To: Nathan Scott Cc: Steve Lord , tes@sgi.com, linux-xfs@oss.sgi.com Subject: Re: xfs recovery oops in 2.6.4-mm1 Message-ID: <20040314233604.GV655@holomorphy.com> References: <20040312100025.GP655@holomorphy.com> <4051D517.4070005@xfs.org> <20040312233153.GT655@holomorphy.com> <4052834B.5010208@xfs.org> <20040314233054.GA643@frodo> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040314233054.GA643@frodo> Organization: The Domain of Holomorphy User-Agent: Mutt/1.5.5.1+cvs20040105i Content-Transfer-Encoding: 8bit X-archive-position: 2451 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wli@holomorphy.com Precedence: bulk X-list: linux-xfs Content-Length: 1220 Lines: 30 On Fri, Mar 12, 2004 at 09:19:51AM -0600, Steve Lord wrote: >> Have you successfully used xfs on this box with older kernels, or is >> this a new filesystem? Was this the first mount under 2.6.4-mm1? On Mon, Mar 15, 2004 at 10:30:54AM +1100, Nathan Scott wrote: > This would be useful to know. I created it first with 2.6.3-mm4. On Mon, Mar 15, 2004 at 10:30:54AM +1100, Nathan Scott wrote: > Attached is a test program thats been used to exercise log > recovery in a more user-friendly fashion. It uses the xfs > forced-shutdown mode to get a dirty log without having to > pull the plug. So, generate traffic, shutdown, unmount, & > then the next mount will do log recovery. If you find the > right traffic to generate a reproducible failure, diagnosing > this becomes a whole lot easier. There's other tools for > generating all manner of different types of traffic in the > xfstests directory in the xfs userspace cvs too - fsstress > is a good one for generating lots of metadata operations. Well, it sort of crapped itself in the midst of doing large recovery ops, so I think marking it dirty and replaying nothing won't fly, but pulling the plug in the midst of fsstress sounds like a good bet. -- wli From owner-linux-xfs@oss.sgi.com Sun Mar 14 15:39:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Mar 2004 15:39:34 -0800 (PST) Received: from mx.leogic.com (mx.leogic.com [62.245.182.8]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2ENdVKO002027 for ; Sun, 14 Mar 2004 15:39:31 -0800 Received: from leogic.com (pD9E4E8A1.dip.t-dialin.net [217.228.232.161]) (authenticated bits=0) by mx.leogic.com (8.12.11/8.12.10) with ESMTP id i2ENdOXr003482 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 15 Mar 2004 00:39:24 +0100 Message-ID: <4054ED0C.3000408@leogic.com> Date: Mon, 15 Mar 2004 00:38:52 +0100 From: Errikos Pitsos Organization: leogic User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040314 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: closed-unsubscription? [Fwd: Ecartis command results: unsubscribe linux-xfs ep@leogic.com] X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2452 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ep@leogic.com Precedence: bulk X-list: linux-xfs Content-Length: 725 Lines: 26 As there is no email address for the list-owner in the headers of emails of this list nor on the sgi webpage, may I ask, why this list is "closed-unsubscription"? Why should people not be allowed to unsubscribe? Please list admin authorize my request for unsubscription. Thanks. cheers erik -------- Original Message -------- Subject: Ecartis command results: unsubscribe linux-xfs ep@leogic.com Date: Sat, 13 Mar 2004 11:32:29 -0800 (PST) From: Ecartis {u} To: ep@leogic.com List context changed to 'linux-xfs' by following command. >> unsubscribe linux-xfs ep@leogic.com List is closed-unsubscription, request has been forwarded to list admins. --- Ecartis v1.0.0 - job execution complete. From owner-linux-xfs@oss.sgi.com Sun Mar 14 15:51:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Mar 2004 15:52:01 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2ENpwKO002680 for ; Sun, 14 Mar 2004 15:51:58 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2F1rOUN001655 for ; Sun, 14 Mar 2004 17:53:25 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA18833; Mon, 15 Mar 2004 10:51:50 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2ENpmFx345838; Mon, 15 Mar 2004 10:51:49 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i2ENpKGN000870; Mon, 15 Mar 2004 10:51:21 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i2ENpJs9000868; Mon, 15 Mar 2004 10:51:19 +1100 Date: Mon, 15 Mar 2004 10:51:19 +1100 From: Nathan Scott To: William Lee Irwin III Cc: Steve Lord , tes@sgi.com, linux-xfs@oss.sgi.com Subject: Re: xfs recovery oops in 2.6.4-mm1 Message-ID: <20040314235119.GB643@frodo> References: <20040312100025.GP655@holomorphy.com> <4051D517.4070005@xfs.org> <20040312233153.GT655@holomorphy.com> <4052834B.5010208@xfs.org> <20040314233054.GA643@frodo> <20040314233604.GV655@holomorphy.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040314233604.GV655@holomorphy.com> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2453 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1696 Lines: 43 On Sun, Mar 14, 2004 at 03:36:04PM -0800, William Lee Irwin III wrote: > On Fri, Mar 12, 2004 at 09:19:51AM -0600, Steve Lord wrote: > >> Have you successfully used xfs on this box with older kernels, or is > >> this a new filesystem? Was this the first mount under 2.6.4-mm1? > > On Mon, Mar 15, 2004 at 10:30:54AM +1100, Nathan Scott wrote: > > This would be useful to know. > > I created it first with 2.6.3-mm4. ok, thanks. did you see these recovery problems with that kernel too, or is it specific to this later one? > On Mon, Mar 15, 2004 at 10:30:54AM +1100, Nathan Scott wrote: > > Attached is a test program thats been used to exercise log > > recovery in a more user-friendly fashion. It uses the xfs > > forced-shutdown mode to get a dirty log without having to > > pull the plug. So, generate traffic, shutdown, unmount, & > > then the next mount will do log recovery. If you find the > > right traffic to generate a reproducible failure, diagnosing > > this becomes a whole lot easier. There's other tools for > > generating all manner of different types of traffic in the > > xfstests directory in the xfs userspace cvs too - fsstress > > is a good one for generating lots of metadata operations. > > Well, it sort of crapped itself in the midst of doing large > recovery ops, so I think marking it dirty and replaying nothing > won't fly, thats not quite what this does - the forced shutdown will cause a real filesystem recovery to run on the next mount. try with -f too to flush the log (but not metadata) during shutdown. > but pulling the plug in the midst of fsstress sounds > like a good bet. thats a rather painful way to do testing :). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Mar 14 16:02:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Mar 2004 16:03:04 -0800 (PST) Received: from holomorphy.com (mail@holomorphy.com [207.189.100.168]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2F02oKO003319 for ; Sun, 14 Mar 2004 16:02:50 -0800 Received: from wli by holomorphy.com with local (Exim 3.36 #1 (Debian)) id 1B2fZ6-0005Sk-00; Sun, 14 Mar 2004 16:02:44 -0800 Date: Sun, 14 Mar 2004 16:02:44 -0800 From: William Lee Irwin III To: Nathan Scott Cc: Steve Lord , tes@sgi.com, linux-xfs@oss.sgi.com Subject: Re: xfs recovery oops in 2.6.4-mm1 Message-ID: <20040315000244.GW655@holomorphy.com> References: <20040312100025.GP655@holomorphy.com> <4051D517.4070005@xfs.org> <20040312233153.GT655@holomorphy.com> <4052834B.5010208@xfs.org> <20040314233054.GA643@frodo> <20040314233604.GV655@holomorphy.com> <20040314235119.GB643@frodo> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040314235119.GB643@frodo> Organization: The Domain of Holomorphy User-Agent: Mutt/1.5.5.1+cvs20040105i Content-Transfer-Encoding: 8bit X-archive-position: 2454 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wli@holomorphy.com Precedence: bulk X-list: linux-xfs Content-Length: 1751 Lines: 44 On Sun, Mar 14, 2004 at 03:36:04PM -0800, William Lee Irwin III wrote: >> I created it first with 2.6.3-mm4. On Mon, Mar 15, 2004 at 10:51:19AM +1100, Nathan Scott wrote: > ok, thanks. did you see these recovery problems with that > kernel too, or is it specific to this later one? It happened there, too. I pulled the plug during a 2.6.4-mm1 run, 2.6.4-mm1 went down on the way back up, I pulled the plug again and booted 2.6.3-mm4, and that went down during recovery too. On Sun, Mar 14, 2004 at 03:36:04PM -0800, William Lee Irwin III wrote: >> Well, it sort of crapped itself in the midst of doing large >> recovery ops, so I think marking it dirty and replaying nothing >> won't fly, On Mon, Mar 15, 2004 at 10:51:19AM +1100, Nathan Scott wrote: > thats not quite what this does - the forced shutdown will cause > a real filesystem recovery to run on the next mount. try with > -f too to flush the log (but not metadata) during shutdown. Okay, I can try that out too. On Sun, Mar 14, 2004 at 03:36:04PM -0800, William Lee Irwin III wrote: >> but pulling the plug in the midst of fsstress sounds >> like a good bet. On Mon, Mar 15, 2004 at 10:51:19AM +1100, Nathan Scott wrote: > thats a rather painful way to do testing :). Well, I have tried pulling the plug while the fs is idle since, but that doesn't trigger it during recovery. When I triggered this, an app that put about 8000 16MB-sized (dio) aio's in flight was in progress. That looks like too slow a way to do it since I waited a while before pulling the plug (impatience was why I tried it), but afterward, pulling the plug too soon didn't trigger it either. I only got it to happen again if I waited about an hour into that before pulling the plug on the stuff. -- wli From owner-linux-xfs@oss.sgi.com Sun Mar 14 21:41:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Mar 2004 21:41:44 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2F5ffKO017515 for ; Sun, 14 Mar 2004 21:41:41 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2F6fpiQ006641 for ; Sun, 14 Mar 2004 22:41:51 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2F5fZKe35397244; Sun, 14 Mar 2004 23:41:35 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i2F5fZEr2194369; Sun, 14 Mar 2004 23:41:35 -0600 (CST) Date: Sun, 14 Mar 2004 23:41:34 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Errikos Pitsos cc: linux-xfs@oss.sgi.com Subject: Re: closed-unsubscription? [Fwd: Ecartis command results: unsubscribe linux-xfs ep@leogic.com] In-Reply-To: <4054ED0C.3000408@leogic.com> Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2456 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 962 Lines: 38 Odd, I don't know why it was set this way - I believe it's fixed now, would you please try another unsubscribe request? Thanks, -Eric On Mon, 15 Mar 2004, Errikos Pitsos wrote: > As there is no email address for the list-owner in the headers of emails > of this list nor on the sgi webpage, may I ask, why this list is > "closed-unsubscription"? Why should people not be allowed to unsubscribe? > > Please list admin authorize my request for unsubscription. > > Thanks. > > cheers > erik > > -------- Original Message -------- > Subject: Ecartis command results: unsubscribe linux-xfs ep@leogic.com > Date: Sat, 13 Mar 2004 11:32:29 -0800 (PST) > From: Ecartis {u} > To: ep@leogic.com > > > List context changed to 'linux-xfs' by following command. > >> unsubscribe linux-xfs ep@leogic.com > List is closed-unsubscription, request has been forwarded to list admins. > > --- > Ecartis v1.0.0 - job execution complete. > > > From owner-linux-xfs@oss.sgi.com Sun Mar 14 21:45:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Mar 2004 21:45:43 -0800 (PST) Received: from mx.leogic.com (mx.leogic.com [62.245.182.8]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2F5jeKO017997 for ; Sun, 14 Mar 2004 21:45:40 -0800 Received: from leogic.com (p50805BF7.dip.t-dialin.net [80.128.91.247]) (authenticated bits=0) by mx.leogic.com (8.12.11/8.12.10) with ESMTP id i2F5jWZv027267 (version=TLSv1/SSLv3 cipher=IDEA-CBC-SHA bits=128 verify=NO); Mon, 15 Mar 2004 06:45:34 +0100 Message-ID: <405542D3.5020104@leogic.com> Date: Mon, 15 Mar 2004 06:44:51 +0100 From: "Errikos Pitsos {secure}" Organization: leogic User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040314 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Eric Sandeen {unsecure}" CC: "linux-xfs@oss.sgi.com {unsecure}" Subject: Re: closed-unsubscription? [Fwd: Ecartis command results: unsubscribe linux-xfs ep@leogic.com] References: In-Reply-To: X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2457 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ep@leogic.com Precedence: bulk X-list: linux-xfs Content-Length: 1048 Lines: 50 it works. thanks. erik Eric Sandeen {u} wrote: > Odd, I don't know why it was set this way - I believe > it's fixed now, would you please try another unsubscribe > request? > > Thanks, > > -Eric > > On Mon, 15 Mar 2004, Errikos Pitsos wrote: > > >>As there is no email address for the list-owner in the headers of emails >>of this list nor on the sgi webpage, may I ask, why this list is >>"closed-unsubscription"? Why should people not be allowed to unsubscribe? >> >>Please list admin authorize my request for unsubscription. >> >>Thanks. >> >>cheers >>erik >> >>-------- Original Message -------- >>Subject: Ecartis command results: unsubscribe linux-xfs ep@leogic.com >>Date: Sat, 13 Mar 2004 11:32:29 -0800 (PST) >>From: Ecartis {u} >>To: ep@leogic.com >> >> >>List context changed to 'linux-xfs' by following command. >> >>>>unsubscribe linux-xfs ep@leogic.com >> >>List is closed-unsubscription, request has been forwarded to list admins. >> >>--- >>Ecartis v1.0.0 - job execution complete. >> >> >> > > > From owner-linux-xfs@oss.sgi.com Mon Mar 15 09:39:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Mar 2004 09:39:10 -0800 (PST) Received: from imap2.fnal.gov (imap2.fnal.gov [131.225.111.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2FHd1KO016799 for ; Mon, 15 Mar 2004 09:39:01 -0800 Received: from conversion-daemon.imap2.fnal.gov by imap2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) id <0HUM00I01OVJMU@imap2.fnal.gov> (original mail from yocum@fnal.gov) for linux-xfs@oss.sgi.com; Mon, 15 Mar 2004 11:39:00 -0600 (CST) Received: from fnal.gov (sdsslnx13.fnal.gov [131.225.7.152]) by imap2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HUM00AIHP0ZJL@imap2.fnal.gov> for linux-xfs@oss.sgi.com; Mon, 15 Mar 2004 11:38:59 -0600 (CST) Date: Mon, 15 Mar 2004 11:38:59 -0600 From: Dan Yocum Subject: XFS pseudo OOPs. To: xfs-list Message-id: <4055EA33.5030608@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 X-archive-position: 2458 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yocum@fnal.gov Precedence: bulk X-list: linux-xfs Content-Length: 6420 Lines: 138 I don't know, yet, if this is a hardware or a software problem. I'm trying to figure that out. I'm using the ATRpms kernel (2.4.20-30_37 w XFSv1.3.0 et al. see the list at http://atrpms.physik.fu-berlin.de/dist/rh73/kernel/ ) and I'm getting these errors and sometimes it forces the FS offline or makes the system unusable - not really a freeze, but you can't interrupt it. Mar 1 14:21:25 sdssdp37 kernel: Filesystem "md(9,3)": XFS internal error xfs_btree_check_sblock at line 341 of file xfs_btree.c. Caller 0xf886c543 ... Here's the ksymoops output: [root@sdssdp38 system_probs_031504]# ksymoops -l /proc/modules sdssdp37-oops1 ksymoops 2.4.4 on i686 2.4.20-30_37.rh7.3.atcustom. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (specified) -o /lib/modules/2.4.20-30_37.rh7.3.atcustom/ (default) -m /boot/System.map-2.4.20-30_37.rh7.3.atcustom (default) Error (expand_objects): cannot stat(/lib/xfs.o) for xfs ksymoops: No such file or directory Error (expand_objects): cannot stat(/lib/raid0.o) for raid0 ksymoops: No such file or directory Error (expand_objects): cannot stat(/lib/3w-xxxx.o) for 3w-xxxx ksymoops: No such file or directory Error (expand_objects): cannot stat(/lib/sd_mod.o) for sd_mod ksymoops: No such file or directory Error (expand_objects): cannot stat(/lib/scsi_mod.o) for scsi_mod ksymoops: No such file or directory Warning (map_ksym_to_module): cannot match loaded module raid0 to a unique module object. Trace may not be reliable. Mar 1 14:26:07 sdssdp37 kernel: c46f1974 f88566df f88b4778 00000001 f74b4400 f88b473b 00000155 f8841909 Mar 1 14:26:07 sdssdp37 kernel: 00000000 cd337fb0 e13bb000 cd337f70 f8841909 cd337f70 e13bb000 00000000 Mar 1 14:26:07 sdssdp37 kernel: f7020b80 cd337f70 00000000 f7020b80 c46f19c8 f7020b80 c4efe000 f885667f Mar 1 14:26:07 sdssdp37 kernel: Call Trace: [] (0xc46f1978)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f197c)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1988)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1990)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f19a4)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f19d0)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f19fc)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1a48)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1a7c)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1aa8)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1ac0)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1ad0)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1afc)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1b4c)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1b5c)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1b68)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1bec)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1bfc)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1ca0)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1cd8)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1cdc)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1cf4)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1d68)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1d7c)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1d94)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1db8)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1e14)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1e4c)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1e90)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1eac)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1ee0)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1f10)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1fb4)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1fc4)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1fc8)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1fd4)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1fe8)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1ff0)) Mar 1 14:26:07 sdssdp37 kernel: [] (0xc46f1ff8)) Warning (Oops_read): Code line not seen, dumping what data is available Trace; f88566df <[xfs]xfs_btree_check_sblock+9f/c0> Trace; f88b4778 <[xfs].rodata.end+6179/14461> Trace; f88b473b <[xfs].rodata.end+613c/14461> Trace; f8841909 <[xfs]xfs_alloc_increment+159/180> Trace; f8841909 <[xfs]xfs_alloc_increment+159/180> Trace; f885667f <[xfs]xfs_btree_check_sblock+3f/c0> Trace; f88405e9 <[xfs]xfs_alloc_lookup+289/350> Trace; f883d60a <[xfs]xfs_alloc_ag_vextent_size+4a/440> Trace; f883e81d <[xfs]xfs_alloc_log_agf+3d/50> Trace; f883c800 <[xfs]xfs_alloc_ag_vextent+b0/f0> Trace; f883c77d <[xfs]xfs_alloc_ag_vextent+2d/f0> Trace; f883ed9a <[xfs]xfs_alloc_vextent+2ca/350> Trace; f884bfa1 <[xfs]xfs_bmap_alloc+ed1/1150> Trace; f88551dc <[xfs]xfs_bmbt_get_state+1c/20> Trace; f884d9b4 <[xfs]xfs_bmap_do_search_extents+344/370> Trace; f8848641 <[xfs]xfs_bmap_add_extent+341/380> Trace; f884f2ad <[xfs]xfs_bmapi+73d/10a0> Trace; f884d9b4 <[xfs]xfs_bmap_do_search_extents+344/370> Trace; f88756a6 <[xfs]xfs_log_reserve+86/90> Trace; f8882300 <[xfs]xfs_trans_reserve+30/170> Trace; f884e610 <[xfs]xfs_bmap_last_offset+d0/f0> Trace; f8895d37 <[xfs]xfs_iomap_write_allocate+287/410> Trace; c019bfea Trace; f889a546 <[xfs]lock_wait+a6/e0> Trace; f889512a <[xfs]xfs_iomap+20a/3e0> Trace; f889523e <[xfs]xfs_iomap+31e/3e0> Trace; f88911ff <[xfs]map_blocks+7f/f0> Trace; f8891d5c <[xfs]page_state_convert+23c/4b0> Trace; c01192cc Trace; c019bfea Trace; f8892430 <[xfs]linvfs_writepage+c0/110> Trace; c0147382 Trace; c014ac19 Trace; c014b01d Trace; c014aef0 Trace; c0105000 <_stext+0/0> Trace; c0105000 <_stext+0/0> Trace; c0107266 Trace; c014aef0 2 warnings and 5 errors issued. Results may not be reliable. I've got other traces that go along with this which I'd be happy to include if requested. Thanks, Dan -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. There is no spoon. From owner-linux-xfs@oss.sgi.com Mon Mar 15 21:51:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Mar 2004 21:51:23 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2G5pKKO002948 for ; Mon, 15 Mar 2004 21:51:20 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2G7qvxQ026458 for ; Mon, 15 Mar 2004 23:52:58 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA20952; Tue, 16 Mar 2004 16:51:10 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2G5p6Fx382921; Tue, 16 Mar 2004 16:51:07 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i2G5ocb5002117; Tue, 16 Mar 2004 16:50:38 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i2G5oaco002115; Tue, 16 Mar 2004 16:50:36 +1100 Date: Tue, 16 Mar 2004 16:50:36 +1100 From: Nathan Scott To: Dan Yocum Cc: xfs-list Subject: Re: XFS pseudo OOPs. Message-ID: <20040316055036.GA2067@frodo> References: <4055EA33.5030608@fnal.gov> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4055EA33.5030608@fnal.gov> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2459 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1453 Lines: 35 On Mon, Mar 15, 2004 at 11:38:59AM -0600, Dan Yocum wrote: > I don't know, yet, if this is a hardware or a software problem. I'm trying > to figure that out. > > I'm using the ATRpms kernel (2.4.20-30_37 w XFSv1.3.0 et al. see the list at > http://atrpms.physik.fu-berlin.de/dist/rh73/kernel/ ) and I'm getting these > errors and sometimes it forces the FS offline or makes the system unusable - > not really a freeze, but you can't interrupt it. > > Mar 1 14:21:25 sdssdp37 kernel: Filesystem "md(9,3)": XFS internal error > xfs_btree_check_sblock at line 341 of file xfs_btree.c. Caller 0xf886c543 ... > ... > Trace; f88566df <[xfs]xfs_btree_check_sblock+9f/c0> > Trace; f88b4778 <[xfs].rodata.end+6179/14461> > Trace; f88b473b <[xfs].rodata.end+613c/14461> > Trace; f8841909 <[xfs]xfs_alloc_increment+159/180> > Trace; f8841909 <[xfs]xfs_alloc_increment+159/180> > Trace; f885667f <[xfs]xfs_btree_check_sblock+3f/c0> > Trace; f88405e9 <[xfs]xfs_alloc_lookup+289/350> > Trace; f883d60a <[xfs]xfs_alloc_ag_vextent_size+4a/440> Hi Dan, Looks like you've got filesystem corruption, from your trace it looks like its in one of the freespace btrees in an AG header. Its difficult to diagnose whether this is caused by a hardware or software failure - if you can find a pattern or better yet a reproducible test case, that'd help us alot in figuring it out. The output from xfs_repair may provide us additional clues also. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Mar 15 22:30:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Mar 2004 22:30:37 -0800 (PST) Received: from exavio.com.cn ([61.149.142.166]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2G6UGKO004558 for ; Mon, 15 Mar 2004 22:30:29 -0800 Received: from localhost (authenticated user clay@exavio.com.cn) by exavio.com.cn (MDaemon.PRO.v6.8.5.R) with ESMTP id 4-md50000000021.tmp for ; Tue, 16 Mar 2004 14:27:03 +0800 Date: Tue, 16 Mar 2004 14:30:28 +0800 From: Isaac Claymore To: xfs-list Subject: 1.3.1 patches against those old Redhat 7.3 kernels? Message-ID: <20040316063028.GF28307@exavio.com.cn> Mime-Version: 1.0 Content-type: text/plain Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-Authenticated-Sender: clay@exavio.com.cn X-Return-Path: clay@exavio.com.cn X-MDaemon-Deliver-To: linux-xfs@oss.sgi.com Content-Transfer-Encoding: 8bit X-archive-position: 2460 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: clay@exavio.com.cn Precedence: bulk X-list: linux-xfs Content-Length: 890 Lines: 31 Hi list, My company is still running old Redhat 7.3 based kernels on some products, and unfortunately, I'm supposed to port xfs 1.3.1 back to them. I've digged through the list archive, finding only some old xfs patches again rh 73 kernels with stale urls. So, before I get myself started, am I so lucky that someone here happens to have such a patch already? That'd save me quite alot of would-be-duplicated work. Thanks in advance for any hint or suggestion. -- Regards, Isaac () ascii ribbon campaign - against html e-mail /\ - against microsoft attachments -- Attached file included as plaintext by Ecartis -- -- File: signature.asc -- Desc: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAVp8EVKePB8O3zz0RAhS0AJ4wbyAbGF4ywnaR7hF1ckGs9dwFNQCdFhwU IQK9qQP8nSzVhC8pqVC8Flg= =4aCc -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Mon Mar 15 22:36:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Mar 2004 22:36:36 -0800 (PST) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2G6aVKO005068 for ; Mon, 15 Mar 2004 22:36:32 -0800 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i2G6a5Ph017187; Tue, 16 Mar 2004 07:36:25 +0100 Message-ID: <4056A051.5090208@stesmi.com> Date: Tue, 16 Mar 2004 07:36:01 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040219 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Isaac Claymore CC: xfs-list Subject: Re: 1.3.1 patches against those old Redhat 7.3 kernels? References: <20040316063028.GF28307@exavio.com.cn> In-Reply-To: <20040316063028.GF28307@exavio.com.cn> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2461 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 695 Lines: 23 Hi. > My company is still running old Redhat 7.3 based kernels on some > products, and unfortunately, I'm supposed to port xfs 1.3.1 back > to them. I've digged through the list archive, finding only some > old xfs patches again rh 73 kernels with stale urls. > > So, before I get myself started, am I so lucky that someone here > happens to have such a patch already? That'd save me quite alot > of would-be-duplicated work. > > Thanks in advance for any hint or suggestion. > Here's one with 1.3.0 by Axel Thimm: http://atrpms.physik.fu-berlin.de/dist/rh73/kernel/ If that's not good enough you can always use that as a basis for applying the 1.3.1 patch to it instead. // Stefan From owner-linux-xfs@oss.sgi.com Tue Mar 16 00:22:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Mar 2004 00:22:54 -0800 (PST) Received: from smtp-out2.xs4all.nl (smtp-out2.xs4all.nl [194.109.24.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2G8MRKO022312 for ; Tue, 16 Mar 2004 00:22:28 -0800 Received: from auto-nb1.xs4all.nl (host-2.coltex.demon.nl [212.238.252.66]) (authenticated bits=0) by smtp-out2.xs4all.nl (8.12.10/8.12.10) with ESMTP id i2G8MOIJ001728 for ; Tue, 16 Mar 2004 09:22:24 +0100 (CET) Message-Id: <4.3.2.7.2.20040316090548.021d9770@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Mar 2004 09:22:23 +0100 To: linux-xfs@oss.sgi.com From: Seth Mos Subject: Log reservation ran out (2.6.4) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2462 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: seth.mos@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1721 Lines: 42 Starting with 2.6.4-xfs (CVS) I have "Log reservation ran out" error. This is a 150GB NFS exported software raid 5 device with version 2 logs. XFS mounting filesystem md0 Ending clean XFS mount for filesystem: md0 Filesystem "md0": xfs_log_write: reservation ran out. Need to up reservation xfs_force_shutdown(md0,0x8) called from line 1693 of file fs/xfs/xfs_log.c. Return address = 0xc01efe4a Filesystem "md0": Corruption of in-memory data detected. Shutting down filesystem: md0 Please umount the filesystem, and rectify the problem(s) xfs_force_shutdown(md0,0x2) called from line 1291 of file fs/xfs/xfs_log.c. Return address = 0xc01efe4a The filesystem reports no problems in xfs_repair after mounting and unmounting the filesystem. lsautom:~# xfs_info /raid/ meta-data=/raid isize=256 agcount=37, agsize=1048568 blks = sectsz=512 data = bsize=4096 blocks=38399936, imaxpct=25 = sunit=1 swidth=3 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=2 = sectsz=512 sunit=8 blks realtime =none extsz=65536 blocks=0, rtextents=0 Apart from the swidth parameter being incorrect I don't see much wrong with it. IO on the drive is very light and seems to be triggered by the nightly backups. The volume in question is not backed up which makes it even weirder. It just passes by the mountpoint. I have added the debugging flags for a stack trace and I will try to make it fall over. Cheers -- Seth I don't make sense, I don't pretend to either. Questions? From owner-linux-xfs@oss.sgi.com Tue Mar 16 00:29:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Mar 2004 00:30:02 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2G8ToKO023246 for ; Tue, 16 Mar 2004 00:29:50 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 6ABA9FB839; Tue, 16 Mar 2004 02:29:47 -0600 (CST) Date: Tue, 16 Mar 2004 00:29:47 -0800 From: Chris Wedgwood To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: Log reservation ran out (2.6.4) Message-ID: <20040316082947.GA21499@dingdong.cryptoapps.com> References: <4.3.2.7.2.20040316090548.021d9770@pop.xs4all.nl> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20040316090548.021d9770@pop.xs4all.nl> Content-Transfer-Encoding: 8bit X-archive-position: 2463 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 251 Lines: 12 On Tue, Mar 16, 2004 at 09:22:23AM +0100, Seth Mos wrote: > Starting with 2.6.4-xfs (CVS) I have "Log reservation ran out" error. > This is a 150GB NFS exported software raid 5 device with version 2 > logs. Is the volume mounted noikeep? --cw From owner-linux-xfs@oss.sgi.com Tue Mar 16 01:32:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Mar 2004 01:32:33 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2G9WSKO025233 for ; Tue, 16 Mar 2004 01:32:28 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2GBY6hc022152 for ; Tue, 16 Mar 2004 03:34:08 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA23008; Tue, 16 Mar 2004 20:32:11 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2G9W7Fx386188; Tue, 16 Mar 2004 20:32:07 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2G9W4jH387872; Tue, 16 Mar 2004 20:32:04 +1100 (EST) Date: Tue, 16 Mar 2004 20:32:04 +1100 From: Nathan Scott To: Seth Mos Cc: linux-xfs@oss.sgi.com, tes@sgi.com Subject: Re: Log reservation ran out (2.6.4) Message-ID: <20040316203204.B385548@wobbly.melbourne.sgi.com> References: <4.3.2.7.2.20040316090548.021d9770@pop.xs4all.nl> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20040316090548.021d9770@pop.xs4all.nl>; from seth.mos@xs4all.nl on Tue, Mar 16, 2004 at 09:22:23AM +0100 Content-Transfer-Encoding: 8bit X-archive-position: 2464 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 861 Lines: 25 hi Seth, On Tue, Mar 16, 2004 at 09:22:23AM +0100, Seth Mos wrote: > Starting with 2.6.4-xfs (CVS) I have "Log reservation ran out" error. > ... > lsautom:~# xfs_info /raid/ > meta-data=/raid isize=256 agcount=37, agsize=1048568 blks > = sectsz=512 > data = bsize=4096 blocks=38399936, imaxpct=25 > = sunit=1 swidth=3 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=32768, version=2 > = sectsz=512 sunit=8 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > This is a known problem with version 2 logs at the moment - Tim's working on the fix, shouldn't be too far off now (prod, prod ;). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Mar 16 01:49:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Mar 2004 01:49:59 -0800 (PST) Received: from smtp-out1.xs4all.nl (smtp-out1.xs4all.nl [194.109.24.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2G9npKO026267 for ; Tue, 16 Mar 2004 01:49:56 -0800 Received: from auto-nb1.xs4all.nl (host-2.coltex.demon.nl [212.238.252.66]) (authenticated bits=0) by smtp-out1.xs4all.nl (8.12.10/8.12.10) with ESMTP id i2G9njeD034973; Tue, 16 Mar 2004 10:49:46 +0100 (CET) Message-Id: <4.3.2.7.2.20040316104706.02fd2d98@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Mar 2004 10:49:41 +0100 To: Chris Wedgwood From: Seth Mos Subject: Re: Log reservation ran out (2.6.4) Cc: linux-xfs@oss.sgi.com In-Reply-To: <20040316082947.GA21499@dingdong.cryptoapps.com> References: <4.3.2.7.2.20040316090548.021d9770@pop.xs4all.nl> <4.3.2.7.2.20040316090548.021d9770@pop.xs4all.nl> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2465 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: seth.mos@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 714 Lines: 26 At 00:29 16-3-2004 -0800, Chris Wedgwood wrote: >On Tue, Mar 16, 2004 at 09:22:23AM +0100, Seth Mos wrote: > > > Starting with 2.6.4-xfs (CVS) I have "Log reservation ran out" error. > > > This is a 150GB NFS exported software raid 5 device with version 2 > > logs. > >Is the volume mounted noikeep? Not yet :-) I'll make it fall over shortly and put the output in the bugzilla log. 2.6.3-xfs CVS didn't show this problem. Google showed that during 2.4.22 the problem already existed. Which makes we think that 2.6.3 should behave the same, but it doesn't. This is why I sent the mail, this one is new for me since this release :-) Cheers -- Seth I don't make sense, I don't pretend to either. Questions? From owner-linux-xfs@oss.sgi.com Tue Mar 16 03:34:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Mar 2004 03:34:24 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:DJJYqjQR3949wyleMXwanGJvImnNYvyr@12-222-156-122.client.insightBB.com [12.222.156.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2GBYLKO031425 for ; Tue, 16 Mar 2004 03:34:21 -0800 Received: from localhost (burgers.bubbanfriends.org [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 7FFC11421001; Tue, 16 Mar 2004 06:34:41 -0500 (EST) Received: from burgers.bubbanfriends.org ([127.0.0.1]) by localhost (burgers.bubbanfriends.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23812-02; Tue, 16 Mar 2004 06:34:40 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 131971421000; Tue, 16 Mar 2004 06:34:39 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id F248730002A2; Tue, 16 Mar 2004 06:34:39 -0500 (EST) Date: Tue, 16 Mar 2004 06:34:39 -0500 (EST) From: Mike Burger To: Stefan Smietanowski Cc: Isaac Claymore , xfs-list Subject: Re: 1.3.1 patches against those old Redhat 7.3 kernels? In-Reply-To: <4056A051.5090208@stesmi.com> Message-ID: References: <20040316063028.GF28307@exavio.com.cn> <4056A051.5090208@stesmi.com> MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new at bubbanfriends.org Content-Transfer-Encoding: 8bit X-archive-position: 2466 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 1263 Lines: 43 On Tue, 16 Mar 2004, Stefan Smietanowski wrote: > Hi. > > > My company is still running old Redhat 7.3 based kernels on some > > products, and unfortunately, I'm supposed to port xfs 1.3.1 back > > to them. I've digged through the list archive, finding only some > > old xfs patches again rh 73 kernels with stale urls. > > > > So, before I get myself started, am I so lucky that someone here > > happens to have such a patch already? That'd save me quite alot > > of would-be-duplicated work. > > > > Thanks in advance for any hint or suggestion. > > > > Here's one with 1.3.0 by Axel Thimm: > > http://atrpms.physik.fu-berlin.de/dist/rh73/kernel/ > > If that's not good enough you can always use that as a basis for > applying the 1.3.1 patch to it instead. As I recall, the only real difference between 1.3.0 and 1.3.1 were some documentation things. Functionally, they should be exactly the same. -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Tue Mar 16 03:37:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Mar 2004 03:37:53 -0800 (PST) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2GBbnKO031867 for ; Tue, 16 Mar 2004 03:37:50 -0800 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i2GBbbPh029268; Tue, 16 Mar 2004 12:37:37 +0100 Message-ID: <4056E702.60402@stesmi.com> Date: Tue, 16 Mar 2004 12:37:38 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040219 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Burger CC: Isaac Claymore , xfs-list Subject: Re: 1.3.1 patches against those old Redhat 7.3 kernels? References: <20040316063028.GF28307@exavio.com.cn> <4056A051.5090208@stesmi.com> In-Reply-To: Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2467 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 1415 Lines: 40 Hi. >>>My company is still running old Redhat 7.3 based kernels on some >>>products, and unfortunately, I'm supposed to port xfs 1.3.1 back >>>to them. I've digged through the list archive, finding only some >>>old xfs patches again rh 73 kernels with stale urls. >>> >>>So, before I get myself started, am I so lucky that someone here >>>happens to have such a patch already? That'd save me quite alot >>>of would-be-duplicated work. >>> >>>Thanks in advance for any hint or suggestion. >>> >> >>Here's one with 1.3.0 by Axel Thimm: >> >>http://atrpms.physik.fu-berlin.de/dist/rh73/kernel/ >> >>If that's not good enough you can always use that as a basis for >>applying the 1.3.1 patch to it instead. > > > As I recall, the only real difference between 1.3.0 and 1.3.1 were some > documentation things. Functionally, they should be exactly the same. Well, wasn't in the case that they also removed something that might be find to be infringing on SCO? I think that was one of the reasons behind 1.3.1. And since it's for a company and not an individual it could be that management of his company decided that they want the latest XFS for that reason alone in which case they'd want 1.3.1 and not 1.3.0. Disclaimer: I do not make any statement whatsoever about the validity (or lack thereof) of any claims whatsoever that SCO has made about anything at all... ever. :) Just so you know :) // Stefan From owner-linux-xfs@oss.sgi.com Tue Mar 16 04:41:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Mar 2004 04:41:20 -0800 (PST) Received: from eik.ii.uib.no (eik.ii.uib.no [129.177.16.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2GCfEKO004468 for ; Tue, 16 Mar 2004 04:41:15 -0800 Received: from lapprose.ii.uib.no ([129.177.20.37]:42609) by eik.ii.uib.no with esmtp (TLSv1:AES256-SHA:256) (Exim 4.30) id 1B38mG-0007hU-Uu; Tue, 16 Mar 2004 08:14:16 +0100 Received: (from jfm@localhost) by lapprose.ii.uib.no (8.12.8/8.12.8/Submit) id i2G7EFIl021576; Tue, 16 Mar 2004 08:14:15 +0100 Date: Tue, 16 Mar 2004 08:14:15 +0100 From: Jan-Frode Myklebust To: Isaac Claymore Cc: xfs-list Subject: Re: 1.3.1 patches against those old Redhat 7.3 kernels? Message-ID: <20040316071414.GA21484@ii.uib.no> References: <20040316063028.GF28307@exavio.com.cn> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040316063028.GF28307@exavio.com.cn> Content-Transfer-Encoding: 8bit X-archive-position: 2468 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: janfrode@parallab.uib.no Precedence: bulk X-list: linux-xfs Content-Length: 623 Lines: 20 On Tue, Mar 16, 2004 at 02:30:28PM +0800, Isaac Claymore wrote: > > So, before I get myself started, am I so lucky that someone here > happens to have such a patch already? That'd save me quite alot > of would-be-duplicated work. > AFAIK just before redhat stopped supporting redhat-8 and redhat-7 they syncronized the kernels for these versions, so you should be able to use this one: ftp://ftp.ii.uib.no/pub/janfrode/XFS/rh8/SRPMS/kernel-2.4.20-30.8.XFS1.3.1.src.rpm or one of the binary rpms under ftp://ftp.ii.uib.no/pub/janfrode/XFS/rh8/i686/ . These are pure XFS-1.3.1 + redhats patches. No extras. -jf From owner-linux-xfs@oss.sgi.com Tue Mar 16 05:51:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Mar 2004 05:51:37 -0800 (PST) Received: from imap1.fnal.gov (imap1.fnal.gov [131.225.111.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2GDpCKO006114 for ; Tue, 16 Mar 2004 05:51:12 -0800 Received: from conversion-daemon.imap1.fnal.gov by imap1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) id <0HUO00H018G6CE@imap1.fnal.gov> (original mail from yocum@fnal.gov) for linux-xfs@oss.sgi.com; Tue, 16 Mar 2004 07:51:11 -0600 (CST) Received: from fnal.gov (sdsslnx13.fnal.gov [131.225.7.152]) by imap1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HUO004FF957TA@imap1.fnal.gov>; Tue, 16 Mar 2004 07:51:11 -0600 (CST) Date: Tue, 16 Mar 2004 07:51:07 -0600 From: Dan Yocum Subject: Re: XFS pseudo OOPs. In-reply-to: <20040316055036.GA2067@frodo> To: Nathan Scott Cc: xfs-list Message-id: <4057064B.8040508@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 References: <4055EA33.5030608@fnal.gov> <20040316055036.GA2067@frodo> X-archive-position: 2469 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yocum@fnal.gov Precedence: bulk X-list: linux-xfs Content-Length: 2145 Lines: 57 Nathan, If an md device decided to go wonko would that make it look like a FS corruption? For instance, these FSs are RAID50 (hw raid5, sw raid0) across 3 volumes. I got to thinking about the kernel I've been using from ATrpms and I know he added an LVM patch. I haven't looked at it, yet, but maybe it touches something in the kernel that md doesn't like. Also, now that I'm back to my old standby kernel (2.4.18-26 + XFS v1.2) I'm not getting these errors/traces. Thoughts? Thanks, Dan Nathan Scott wrote: > On Mon, Mar 15, 2004 at 11:38:59AM -0600, Dan Yocum wrote: > >>I don't know, yet, if this is a hardware or a software problem. I'm trying >>to figure that out. >> >>I'm using the ATRpms kernel (2.4.20-30_37 w XFSv1.3.0 et al. see the list at >>http://atrpms.physik.fu-berlin.de/dist/rh73/kernel/ ) and I'm getting these >>errors and sometimes it forces the FS offline or makes the system unusable - >>not really a freeze, but you can't interrupt it. >> >>Mar 1 14:21:25 sdssdp37 kernel: Filesystem "md(9,3)": XFS internal error >>xfs_btree_check_sblock at line 341 of file xfs_btree.c. Caller 0xf886c543 ... >>... >>Trace; f88566df <[xfs]xfs_btree_check_sblock+9f/c0> >>Trace; f88b4778 <[xfs].rodata.end+6179/14461> >>Trace; f88b473b <[xfs].rodata.end+613c/14461> >>Trace; f8841909 <[xfs]xfs_alloc_increment+159/180> >>Trace; f8841909 <[xfs]xfs_alloc_increment+159/180> >>Trace; f885667f <[xfs]xfs_btree_check_sblock+3f/c0> >>Trace; f88405e9 <[xfs]xfs_alloc_lookup+289/350> >>Trace; f883d60a <[xfs]xfs_alloc_ag_vextent_size+4a/440> > > > Hi Dan, > > Looks like you've got filesystem corruption, from your trace it > looks like its in one of the freespace btrees in an AG header. > Its difficult to diagnose whether this is caused by a hardware > or software failure - if you can find a pattern or better yet a > reproducible test case, that'd help us alot in figuring it out. > The output from xfs_repair may provide us additional clues also. > > thanks. > -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. There is no spoon. From owner-linux-xfs@oss.sgi.com Tue Mar 16 09:41:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Mar 2004 09:41:30 -0800 (PST) Received: from imap1.fnal.gov (imap1.fnal.gov [131.225.111.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2GHfPKO016236 for ; Tue, 16 Mar 2004 09:41:25 -0800 Received: from conversion-daemon.imap1.fnal.gov by imap1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) id <0HUO00801JP79D@imap1.fnal.gov> (original mail from yocum@fnal.gov) for linux-xfs@oss.sgi.com; Tue, 16 Mar 2004 11:41:25 -0600 (CST) Received: from fnal.gov (sdsslnx13.fnal.gov [131.225.7.152]) by imap1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HUO00E6NJSZ9C@imap1.fnal.gov>; Tue, 16 Mar 2004 11:41:24 -0600 (CST) Date: Tue, 16 Mar 2004 11:41:23 -0600 From: Dan Yocum Subject: Re: XFS pseudo OOPs. In-reply-to: <4057064B.8040508@fnal.gov> To: xfs-list Cc: Nathan Scott Message-id: <40573C43.30709@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 References: <4055EA33.5030608@fnal.gov> <20040316055036.GA2067@frodo> <4057064B.8040508@fnal.gov> X-archive-position: 2470 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yocum@fnal.gov Precedence: bulk X-list: linux-xfs Content-Length: 2701 Lines: 75 I just took a look at the extra lvm patch (v1.0.7) that Axel has added to his AT kernel. It's touching fs/buffer.c and fs/super.c as well as [reiser|ext3]/[buffer.c|super.c] but nothing in the xfs tree. Since two of the errors I've seen mention xfs_da_do_buf and xfs_btree_check_sblock I'm going to take a wild guess that this is the problem. IANAKD, so I could be wrong. I'm going to give Jan-Frode's kernel a go and see if it's got the same problem. Cheers, Dan Dan Yocum wrote: > Nathan, > > If an md device decided to go wonko would that make it look like a FS > corruption? For instance, these FSs are RAID50 (hw raid5, sw raid0) across > 3 volumes. I got to thinking about the kernel I've been using from ATrpms > and I know he added an LVM patch. I haven't looked at it, yet, but maybe it > touches something in the kernel that md doesn't like. Also, now that I'm > back to my old standby kernel (2.4.18-26 + XFS v1.2) I'm not getting these > errors/traces. > > Thoughts? > > Thanks, > Dan > > Nathan Scott wrote: > >>On Mon, Mar 15, 2004 at 11:38:59AM -0600, Dan Yocum wrote: >> >> >>>I don't know, yet, if this is a hardware or a software problem. I'm trying >>>to figure that out. >>> >>>I'm using the ATRpms kernel (2.4.20-30_37 w XFSv1.3.0 et al. see the list at >>>http://atrpms.physik.fu-berlin.de/dist/rh73/kernel/ ) and I'm getting these >>>errors and sometimes it forces the FS offline or makes the system unusable - >>>not really a freeze, but you can't interrupt it. >>> >>>Mar 1 14:21:25 sdssdp37 kernel: Filesystem "md(9,3)": XFS internal error >>>xfs_btree_check_sblock at line 341 of file xfs_btree.c. Caller 0xf886c543 ... >>>... >>>Trace; f88566df <[xfs]xfs_btree_check_sblock+9f/c0> >>>Trace; f88b4778 <[xfs].rodata.end+6179/14461> >>>Trace; f88b473b <[xfs].rodata.end+613c/14461> >>>Trace; f8841909 <[xfs]xfs_alloc_increment+159/180> >>>Trace; f8841909 <[xfs]xfs_alloc_increment+159/180> >>>Trace; f885667f <[xfs]xfs_btree_check_sblock+3f/c0> >>>Trace; f88405e9 <[xfs]xfs_alloc_lookup+289/350> >>>Trace; f883d60a <[xfs]xfs_alloc_ag_vextent_size+4a/440> >> >> >>Hi Dan, >> >>Looks like you've got filesystem corruption, from your trace it >>looks like its in one of the freespace btrees in an AG header. >>Its difficult to diagnose whether this is caused by a hardware >>or software failure - if you can find a pattern or better yet a >>reproducible test case, that'd help us alot in figuring it out. >>The output from xfs_repair may provide us additional clues also. >> >>thanks. >> > > -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. There is no spoon. From owner-linux-xfs@oss.sgi.com Tue Mar 16 10:14:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Mar 2004 10:14:47 -0800 (PST) Received: from imap1.fnal.gov (imap1.fnal.gov [131.225.111.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2GIEiKO017261 for ; Tue, 16 Mar 2004 10:14:44 -0800 Received: from conversion-daemon.imap1.fnal.gov by imap1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) id <0HUO00G01L7QXS@imap1.fnal.gov> (original mail from yocum@fnal.gov) for linux-xfs@oss.sgi.com; Tue, 16 Mar 2004 12:14:43 -0600 (CST) Received: from fnal.gov (sdsslnx13.fnal.gov [131.225.7.152]) by imap1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HUO00E2TLCI9B@imap1.fnal.gov>; Tue, 16 Mar 2004 12:14:43 -0600 (CST) Date: Tue, 16 Mar 2004 12:14:42 -0600 From: Dan Yocum Subject: Re: 1.3.1 patches against those old Redhat 7.3 kernels? In-reply-to: <20040316071414.GA21484@ii.uib.no> To: Jan-Frode Myklebust Cc: xfs-list Message-id: <40574412.2040508@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 References: <20040316063028.GF28307@exavio.com.cn> <20040316071414.GA21484@ii.uib.no> X-archive-position: 2471 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yocum@fnal.gov Precedence: bulk X-list: linux-xfs Content-Length: 1023 Lines: 40 Jan-Frode, Do you happen to have a kernel-source-2.4.20-30.8.XFS1.3.1.i386.rpm laying around somewhere? I don't see it in the i386 dir. (Only releases -24 and -28). Thanks, Dan Jan-Frode Myklebust wrote: > On Tue, Mar 16, 2004 at 02:30:28PM +0800, Isaac Claymore wrote: > >>So, before I get myself started, am I so lucky that someone here >>happens to have such a patch already? That'd save me quite alot >>of would-be-duplicated work. >> > > > AFAIK just before redhat stopped supporting redhat-8 and redhat-7 they > syncronized the kernels for these versions, so you should be able to > use this one: > > ftp://ftp.ii.uib.no/pub/janfrode/XFS/rh8/SRPMS/kernel-2.4.20-30.8.XFS1.3.1.src.rpm > > or one of the binary rpms under ftp://ftp.ii.uib.no/pub/janfrode/XFS/rh8/i686/ . > > These are pure XFS-1.3.1 + redhats patches. No extras. > > > -jf > > > -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. There is no spoon. From owner-linux-xfs@oss.sgi.com Tue Mar 16 11:18:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Mar 2004 11:18:32 -0800 (PST) Received: from eik.ii.uib.no (eik.ii.uib.no [129.177.16.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2GJITKO020059 for ; Tue, 16 Mar 2004 11:18:30 -0800 Received: from lapprose.ii.uib.no ([129.177.20.37]:51764) by eik.ii.uib.no with esmtp (TLSv1:AES256-SHA:256) (Exim 4.30) id 1B3K50-00078Q-Dg; Tue, 16 Mar 2004 20:18:22 +0100 Received: (from jfm@localhost) by lapprose.ii.uib.no (8.12.8/8.12.8/Submit) id i2GJILN7028320; Tue, 16 Mar 2004 20:18:21 +0100 Date: Tue, 16 Mar 2004 20:18:21 +0100 From: Jan-Frode Myklebust To: Dan Yocum Cc: xfs-list Subject: Re: 1.3.1 patches against those old Redhat 7.3 kernels? Message-ID: <20040316191821.GA28289@ii.uib.no> References: <20040316063028.GF28307@exavio.com.cn> <20040316071414.GA21484@ii.uib.no> <40574412.2040508@fnal.gov> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40574412.2040508@fnal.gov> Content-Transfer-Encoding: 8bit X-archive-position: 2472 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: janfrode@parallab.uib.no Precedence: bulk X-list: linux-xfs Content-Length: 283 Lines: 12 On Tue, Mar 16, 2004 at 12:14:42PM -0600, Dan Yocum wrote: > Jan-Frode, > > Do you happen to have a kernel-source-2.4.20-30.8.XFS1.3.1.i386.rpm laying > around somewhere? I don't see it in the i386 dir. (Only releases -24 and > -28). OK, uploaded it to the i386 now.. -jf From owner-linux-xfs@oss.sgi.com Tue Mar 16 11:39:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Mar 2004 11:39:20 -0800 (PST) Received: from moria.linuxis.net (moria.linuxis.net [209.237.231.67]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2GJdGKO022364 for ; Tue, 16 Mar 2004 11:39:16 -0800 Received: (qmail 6849 invoked from network); 16 Mar 2004 19:26:58 -0000 Received: from unknown (HELO shoshana.dnsalias.org) (67.173.135.227) by 209.237.231.80 with SMTP; 16 Mar 2004 19:26:58 -0000 Received: (qmail 1620 invoked by uid 501); 16 Mar 2004 19:39:36 -0000 Date: Tue, 16 Mar 2004 13:39:14 -0600 From: John Palkovic To: linux-xfs@oss.sgi.com Subject: 2.6.4 can't mount root xfs Message-ID: <20040316193914.GA1564@palkovic.org> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i Content-Transfer-Encoding: 8bit X-archive-position: 2473 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scientist@palkovic.org Precedence: bulk X-list: linux-xfs Content-Length: 1996 Lines: 42 The system here is a dell optiplex gx110 workstation, PIII cpu. My boot drive is SCSI hanging off of an adaptec aha-2940uw. lspci output is pasted in below. Kernel 2.6.3 is working great for me, so I guess I'll be sticking with it. I also have a 2.4.21 kernel that boots cleanly on this system. I have a separate /boot partition which is an ext2. All other partitions (/, /usr, /home) are xfs. My 2.6.4 kernel source is from the cvs tree at oss.sgi.com. I pulled the update on March 15th, 2004 at around 11 PM central time. config used is at http://shoshana.dnsalias.org/config-2.6.4.txt When I try to boot the resulting kernel, it panics with an unable to mount root fs error: ... VFS: cannot open root device "sda5" or sda5 Please append a correct "root=" boot option Kernel panic: VFS: unable to mount root fs on sda5 john@gx110:~$ uname -a Linux gx110 2.6.3 #1 Thu Mar 11 10:11:29 CST 2004 i686 GNU/Linux john@gx110:~$ lspci 00:00.0 Host bridge: Intel Corp. 82810E DC-133 GMCH [Graphics Memory Controller Hub] (rev 03) 00:01.0 VGA compatible controller: Intel Corp. 82810E DC-133 CGC [Chipset Graphics Controller] (rev 03) 00:1e.0 PCI bridge: Intel Corp. 82801AA PCI Bridge (rev 02) 00:1f.0 ISA bridge: Intel Corp. 82801AA ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801AA IDE (rev 02) 00:1f.2 USB Controller: Intel Corp. 82801AA USB (rev 02) 00:1f.3 SMBus: Intel Corp. 82801AA SMBus (rev 02) 01:07.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 09) 01:08.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller 01:09.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U 01:0a.0 FireWire (IEEE 1394): Texas Instruments TSB12LV26 IEEE-1394 Controller (Link) 01:0c.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) -- "The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell From owner-linux-xfs@oss.sgi.com Tue Mar 16 11:44:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Mar 2004 11:44:27 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2GJiNKO023489 for ; Tue, 16 Mar 2004 11:44:24 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1B3KUB-0001JL-E6 for linux-xfs@oss.sgi.com; Tue, 16 Mar 2004 19:44:23 +0000 Date: Tue, 16 Mar 2004 19:44:23 +0000 From: Christoph Hellwig To: linux-xfs@oss.sgi.com Subject: Re: 2.6.4 can't mount root xfs Message-ID: <20040316194423.A4914@infradead.org> References: <20040316193914.GA1564@palkovic.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040316193914.GA1564@palkovic.org>; from scientist@palkovic.org on Tue, Mar 16, 2004 at 01:39:14PM -0600 Content-Transfer-Encoding: 8bit X-archive-position: 2474 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 853 Lines: 19 On Tue, Mar 16, 2004 at 01:39:14PM -0600, John Palkovic wrote: > My 2.6.4 kernel source is from the cvs tree at oss.sgi.com. I pulled the > update on March 15th, 2004 at around 11 PM central time. > config used is at http://shoshana.dnsalias.org/config-2.6.4.txt > > When I try to boot the resulting kernel, it panics with an unable to mount > root fs error: > > ... > VFS: cannot open root device "sda5" or sda5 > Please append a correct "root=" boot option > Kernel panic: VFS: unable to mount root fs on sda5 This is not a XFS issue, the kernel doesn't even get far enough to call the XFS mount code. I've looked at your .config and it seems you have devfs enabled, but don't suply devfs-style names in root=. Best disable devfs or if you think you really want it (I'd strongly advise against devfs) supply a devfs-style device name for root= From owner-linux-xfs@oss.sgi.com Tue Mar 16 11:50:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Mar 2004 11:50:54 -0800 (PST) Received: from saytrin.hq.k1024.org ([62.217.245.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2GJohKO024022 for ; Tue, 16 Mar 2004 11:50:47 -0800 Received: by saytrin.hq.k1024.org (Postfix, from userid 4004) id 1136A129F0; Tue, 16 Mar 2004 21:53:42 +0200 (EET) Date: Tue, 16 Mar 2004 21:53:41 +0200 From: Iustin Pop To: linux-xfs@oss.sgi.com Subject: Re: 2.6.4 can't mount root xfs Message-ID: <20040316195341.GB4059@saytrin.hq.k1024.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20040316193914.GA1564@palkovic.org> <20040316194423.A4914@infradead.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040316194423.A4914@infradead.org> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.5.1+cvs20040105i Content-Transfer-Encoding: 8bit X-archive-position: 2475 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs Content-Length: 1291 Lines: 29 On Tue, Mar 16, 2004 at 07:44:23PM +0000, Christoph Hellwig wrote: > On Tue, Mar 16, 2004 at 01:39:14PM -0600, John Palkovic wrote: > > My 2.6.4 kernel source is from the cvs tree at oss.sgi.com. I pulled the > > update on March 15th, 2004 at around 11 PM central time. > > config used is at http://shoshana.dnsalias.org/config-2.6.4.txt > > > > When I try to boot the resulting kernel, it panics with an unable to mount > > root fs error: > > > > ... > > VFS: cannot open root device "sda5" or sda5 > > Please append a correct "root=" boot option > > Kernel panic: VFS: unable to mount root fs on sda5 > > This is not a XFS issue, the kernel doesn't even get far enough to call > the XFS mount code. I've looked at your .config and it seems you have > devfs enabled, but don't suply devfs-style names in root=. Best disable > devfs or if you think you really want it (I'd strongly advise against > devfs) supply a devfs-style device name for root= Not necesarily. I have (for a long time, on many systems) used devfs and boot with grub with /dev/hda5 or such. AFAIK the kernel just parses the root device specification into a (major, minor) pair and uses that (i.e. the kernel doesn't look into /dev for mounting the root filesystem). But I could also be very wrong :) Iustin Pop From owner-linux-xfs@oss.sgi.com Tue Mar 16 12:11:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Mar 2004 12:11:04 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2GKB1KO025803 for ; Tue, 16 Mar 2004 12:11:01 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1B3Ktw-0001RA-E5 for linux-xfs@oss.sgi.com; Tue, 16 Mar 2004 20:11:00 +0000 Date: Tue, 16 Mar 2004 20:11:00 +0000 From: Christoph Hellwig To: linux-xfs@oss.sgi.com Subject: Re: 2.6.4 can't mount root xfs Message-ID: <20040316201100.A5454@infradead.org> References: <20040316193914.GA1564@palkovic.org> <20040316194423.A4914@infradead.org> <20040316195341.GB4059@saytrin.hq.k1024.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040316195341.GB4059@saytrin.hq.k1024.org>; from iusty@k1024.org on Tue, Mar 16, 2004 at 09:53:41PM +0200 Content-Transfer-Encoding: 8bit X-archive-position: 2476 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 647 Lines: 18 On Tue, Mar 16, 2004 at 09:53:41PM +0200, Iustin Pop wrote: > Not necesarily. I have (for a long time, on many systems) used devfs and > boot with grub with /dev/hda5 or such. With 2.4 kernels you can pass non-devfs names on devfs systems, on 2.6 you can't. > AFAIK the kernel just parses the > root device specification into a (major, minor) pair and uses that (i.e. > the kernel doesn't look into /dev for mounting the root filesystem). for non-devfs kernel that's true. In Linux 2.4 a devfs kernel tries to look it up in devfs in addition and with Linux 2.6 _only_. > But I could also be very wrong :) You weren't that wrong actually :) From owner-linux-xfs@oss.sgi.com Tue Mar 16 12:12:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Mar 2004 12:12:40 -0800 (PST) Received: from moria.linuxis.net (moria.linuxis.net [209.237.231.67]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2GKCcKO026209 for ; Tue, 16 Mar 2004 12:12:38 -0800 Received: (qmail 10300 invoked from network); 16 Mar 2004 20:00:18 -0000 Received: from unknown (HELO shoshana.dnsalias.org) (67.173.135.227) by 209.237.231.80 with SMTP; 16 Mar 2004 20:00:18 -0000 Received: (qmail 1819 invoked by uid 501); 16 Mar 2004 20:12:57 -0000 Date: Tue, 16 Mar 2004 14:12:35 -0600 From: John Palkovic To: linux-xfs@oss.sgi.com Subject: Re: 2.6.4 can't mount root xfs Message-ID: <20040316201235.GB1564@palkovic.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20040316193914.GA1564@palkovic.org> <20040316194423.A4914@infradead.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040316194423.A4914@infradead.org> User-Agent: Mutt/1.5.5.1+cvs20040105i Content-Transfer-Encoding: 8bit X-archive-position: 2477 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scientist@palkovic.org Precedence: bulk X-list: linux-xfs Content-Length: 730 Lines: 20 On Tue, Mar 16, 2004 at 07:44:01PM +0000, Christoph Hellwig wrote: > This is not a XFS issue, the kernel doesn't even get far enough to call > the XFS mount code. I've looked at your .config and it seems you have > devfs enabled, but don't suply devfs-style names in root=. Best disable > devfs or if you think you really want it (I'd strongly advise against > devfs) supply a devfs-style device name for root= I have the identical option set in my 2.6.3 config, and it boots cleanly on the same sytem. I'll try it without CONFIG_DEVFS_FS and report back. -John -- "The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell From owner-linux-xfs@oss.sgi.com Tue Mar 16 13:24:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Mar 2004 13:24:59 -0800 (PST) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2GLOjKO032279 for ; Tue, 16 Mar 2004 13:24:46 -0800 Received: from mitta.sydney (211.26.149.22) by smtp01.syd.iprimus.net.au (7.0.024) id 402BA92700B48281; Wed, 17 Mar 2004 08:24:34 +1100 Received: from mitta.sydney (localhost [127.0.0.1]) by mitta.sydney (8.12.11/8.12.4) with ESMTP id i2GLOWfV003821; Wed, 17 Mar 2004 08:24:32 +1100 Received: (from alciocca@localhost) by mitta.sydney (8.12.11/8.12.11/Submit) id i2GLOWJe003820; Wed, 17 Mar 2004 08:24:32 +1100 Date: Wed, 17 Mar 2004 08:24:32 +1100 From: Adam Cioccarelli To: Christoph Hellwig Cc: linux-xfs@oss.sgi.com Subject: Re: 2.6.4 can't mount root xfs Message-ID: <20040316212432.GA3652@gmx.net> References: <20040316193914.GA1564@palkovic.org> <20040316194423.A4914@infradead.org> <20040316195341.GB4059@saytrin.hq.k1024.org> <20040316201100.A5454@infradead.org> Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20040316201100.A5454@infradead.org> User-Agent: Mutt/1.5.6i Content-Transfer-Encoding: 8bit X-archive-position: 2478 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alciocca@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 905 Lines: 28 That's odd, because I am using 2.6.4 with devfs and I have root=/dev/hdb5 in my lilo.conf. Would having CONFIG_DEVFS_MOUNT=y make a difference? Adam On Tue, Mar 16, 2004 at 08:11:00PM +0000, Christoph Hellwig wrote: > On Tue, Mar 16, 2004 at 09:53:41PM +0200, Iustin Pop wrote: > > Not necesarily. I have (for a long time, on many systems) used devfs and > > boot with grub with /dev/hda5 or such. > > With 2.4 kernels you can pass non-devfs names on devfs systems, on 2.6 > you can't. > > > AFAIK the kernel just parses the > > root device specification into a (major, minor) pair and uses that (i.e. > > the kernel doesn't look into /dev for mounting the root filesystem). > > for non-devfs kernel that's true. In Linux 2.4 a devfs kernel tries to > look it up in devfs in addition and with Linux 2.6 _only_. > > > But I could also be very wrong :) > > You weren't that wrong actually :) > From owner-linux-xfs@oss.sgi.com Tue Mar 16 15:12:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Mar 2004 15:12:54 -0800 (PST) Received: from moria.linuxis.net (moria.linuxis.net [209.237.231.67]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2GNCpKO009482 for ; Tue, 16 Mar 2004 15:12:51 -0800 Received: (qmail 29591 invoked from network); 16 Mar 2004 23:00:30 -0000 Received: from unknown (HELO shoshana.dnsalias.org) (67.173.135.227) by 209.237.231.80 with SMTP; 16 Mar 2004 23:00:30 -0000 Received: (qmail 1552 invoked by uid 501); 16 Mar 2004 23:13:12 -0000 Date: Tue, 16 Mar 2004 17:12:50 -0600 From: John Palkovic To: linux-xfs@oss.sgi.com Subject: Re: 2.6.4 can't mount root xfs Message-ID: <20040316231250.GA1473@palkovic.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20040316193914.GA1564@palkovic.org> <20040316194423.A4914@infradead.org> <20040316201235.GB1564@palkovic.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040316201235.GB1564@palkovic.org> User-Agent: Mutt/1.5.5.1+cvs20040105i Content-Transfer-Encoding: 8bit X-archive-position: 2479 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scientist@palkovic.org Precedence: bulk X-list: linux-xfs Content-Length: 610 Lines: 19 On Tue, Mar 16, 2004 at 02:12:13PM -0600, I wrote: > I'll try it without CONFIG_DEVFS_FS and report back. No joy, my optiplex still does not boot 2.6.4 with CONFIG_DEVFS_FS not set. The symptoms are the same as before. The new config file is at http://shoshana.dnsalias.org/config-2.6.4.txt. A 2.6.3 config, which produces a cleanly booting kernel on the same system, is at http://shoshana.dnsalias.org/config-2.6.3.txt. Any other ideas? -John -- "The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell From owner-linux-xfs@oss.sgi.com Tue Mar 16 21:09:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Mar 2004 21:09:23 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2H594KO027391 for ; Tue, 16 Mar 2004 21:09:04 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2H56bX6023554 for ; Tue, 16 Mar 2004 23:06:38 -0600 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA02611; Wed, 17 Mar 2004 16:06:34 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2H56UFx413420; Wed, 17 Mar 2004 16:06:31 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i2H55xYk003539; Wed, 17 Mar 2004 16:05:59 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i2H55wVv003537; Wed, 17 Mar 2004 16:05:58 +1100 Date: Wed, 17 Mar 2004 16:05:58 +1100 From: Nathan Scott To: Dan Yocum Cc: xfs-list Subject: Re: XFS pseudo OOPs. Message-ID: <20040317050558.GB3045@frodo> References: <4055EA33.5030608@fnal.gov> <20040316055036.GA2067@frodo> <4057064B.8040508@fnal.gov> <40573C43.30709@fnal.gov> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40573C43.30709@fnal.gov> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2480 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 753 Lines: 22 On Tue, Mar 16, 2004 at 11:41:23AM -0600, Dan Yocum wrote: > I just took a look at the extra lvm patch (v1.0.7) that Axel has added to > his AT kernel. It's touching fs/buffer.c and fs/super.c as well as > [reiser|ext3]/[buffer.c|super.c] but nothing in the xfs tree. Since two of Hmmm.. not sure what patch that is - maybe the VFS locking patch for LVM snapshots? If so, its unlikely to be the cause here. > I'm going to give Jan-Frode's kernel a go and see if it's got the same problem. Does that mean you have a reliable failure/test case? If not, could you try to characterise your workloads a bit for me and maybe we can find a pattern of activity thats more likely to trigger it. Any xfs_check/xfs_repair info too? thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Mar 16 21:23:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Mar 2004 21:23:23 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2H5NJKO027951 for ; Tue, 16 Mar 2004 21:23:20 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2H6NgiQ023951 for ; Tue, 16 Mar 2004 22:23:43 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA02895; Wed, 17 Mar 2004 16:23:11 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2H5N7Fx413119; Wed, 17 Mar 2004 16:23:08 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i2H5MaYk003636; Wed, 17 Mar 2004 16:22:37 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i2H5MZIW003634; Wed, 17 Mar 2004 16:22:35 +1100 Date: Wed, 17 Mar 2004 16:22:35 +1100 From: Nathan Scott To: "Ranslam, Robert E" , Vinesh Christopher Cc: linux-xfs@oss.sgi.com Subject: Re: XSF on Xscale Message-ID: <20040317052235.GA3595@frodo> References: <802FECEADA78854F8DD69950B138D8C9025ABC19@orsmsx405.jf.intel.com> <4050B686.1040908@xfs.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4050B686.1040908@xfs.org> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2481 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1913 Lines: 60 On Thu, Mar 11, 2004 at 12:57:10PM -0600, Steve Lord wrote: > > You could probably restructure this into something a little less complex: > > XFS_DIR2_SF_HDR_SIZE(i8count) + > namelen + > count * (sizeof(xfs_dir2_sf_off_t) + 1 + > (i8count ? sizeof(xfs_dir2_ino8_t) : > sizeof(xfs_dir2_ino4_t))) > > I would actually break the conditional expression out of there and see if > that > makes a difference. > > inode_size = i8count ? sizeof(xfs_dir2_ino8_t) : > sizeof(xfs_dir2_ino4_t); > > size = XFS_DIR2_SF_HDR_SIZE(i8count) + > count * (sizeof(xfs_dir2_sf_off_t) + 1 + inode_size); > Based on Steves suggestions, can you guys try this patch to see if it helps at all? It seems to always be coming up with the same values as before on i386 anyway. thanks. -- Nathan --- /usr/tmp/TmpDir.1448-0/xfs_dir2_sf.c_1.37 2004-03-17 16:14:30.000000000 +1100 +++ xfs_dir2_sf.c 2004-03-17 16:14:08.000000000 +1100 @@ -107,6 +107,7 @@ int isdotdot; /* entry is ".." */ xfs_mount_t *mp; /* mount structure pointer */ int namelen; /* total name bytes */ + int inode_size; /* inode number bytes */ xfs_ino_t parent; /* parent inode number */ int size=0; /* total computed size */ @@ -148,13 +149,10 @@ /* * Calculate the new size, see if we should give up yet. */ - size = XFS_DIR2_SF_HDR_SIZE(i8count) + /* header */ - count + /* namelen */ - count * (uint)sizeof(xfs_dir2_sf_off_t) + /* offset */ - namelen + /* name */ - (i8count ? /* inumber */ - (uint)sizeof(xfs_dir2_ino8_t) * count : - (uint)sizeof(xfs_dir2_ino4_t) * count); + inode_size = i8count ? sizeof(xfs_dir2_ino8_t) : + sizeof(xfs_dir2_ino4_t); + size = XFS_DIR2_SF_HDR_SIZE(i8count) + namelen + + count * (sizeof(xfs_dir2_sf_off_t) + 1 + inode_size); if (size > XFS_IFORK_DSIZE(dp)) return size; /* size value is a failure */ } From owner-linux-xfs@oss.sgi.com Tue Mar 16 21:29:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Mar 2004 21:29:36 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2H5TXKO028491 for ; Tue, 16 Mar 2004 21:29:33 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2H6TtiQ024222 for ; Tue, 16 Mar 2004 22:29:56 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA03154 for ; Wed, 17 Mar 2004 16:29:25 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2H5TNFx413128 for ; Wed, 17 Mar 2004 16:29:23 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i2H5SqYk003664 for ; Wed, 17 Mar 2004 16:28:52 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i2H5SqxM003662 for linux-xfs@oss.sgi.com; Wed, 17 Mar 2004 16:28:52 +1100 Date: Wed, 17 Mar 2004 16:28:52 +1100 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: debian-installer beta 3 released (fwd) Message-ID: <20040317052852.GB3595@frodo> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i2H5TXKO028493 X-archive-position: 2482 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2090 Lines: 56 FYI, for any Debian punters out there - the latest Debian installer now has XFS support. So please test it and let those folks know how it goes. cheers. ----- Forwarded message from Joey Hess ----- Date: Tue, 16 Mar 2004 11:57:24 -0500 To: debian-devel-announce@lists.debian.org User-Agent: Mutt/1.5.5.1+cvs20040105i From: Joey Hess Subject: debian-installer beta 3 released X-Mailing-List: The Debian Installer team is once again ready to announce a beta release of the Debian sarge installer. New features in beta 3 include: - new easy to use partitioner that supports automatic partitioning and LVM - grub as the default boot loader on i386 - wireless networking support - 2.4.25 kernel, with SATA support and security fixes - support for the XFS filesystem - support for these architectures: i386, ia64, sparc, m68k (mac), mips, alpha - fully translated to 25 languages - a boot logo (by Mark Riedesel) - a draft installation manual This release fixes all of the posted errata in beta 2 of the Debian Installer, and many other bugs besides. We anticipate that most users will find it a great improvement from past betas. Please send us a report of how your installation goes, so we can strive to make it even better. How to try out the beta: - Download one of the CDs or other images from - Read the INSTALLATION HOWTO and errata before installing. - File an install report as a bug against the pseudo-package 'installation-reports' in the Debian bug tracking system. If your installation was successful, there will be a template for install reports in /root/install-report.template. This template is also available on the web. Please use this template when filing installation reports. We appreciate all the testing and feedback we've received for past versions of the installer, and hope this one is the best one yet! For the Debian Installer team, Joey Hess ----- End forwarded message ----- -- Nathan From owner-linux-xfs@oss.sgi.com Wed Mar 17 01:32:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Mar 2004 01:33:09 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2H9WkKO006565 for ; Wed, 17 Mar 2004 01:32:46 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2H9WkLs006564 for linux-xfs@oss.sgi.com; Wed, 17 Mar 2004 01:32:46 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2H9WhKQ006549 for ; Wed, 17 Mar 2004 01:32:43 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2H9U9Y8006521; Wed, 17 Mar 2004 01:30:09 -0800 Date: Wed, 17 Mar 2004 01:30:09 -0800 Message-Id: <200403170930.i2H9U9Y8006521@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 316] New: C++ compiler errors/warnings X-Bugzilla-Reason: AssignedTo X-archive-position: 2483 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1389 Lines: 43 http://oss.sgi.com/bugzilla/show_bug.cgi?id=316 Summary: C++ compiler errors/warnings Product: Linux XFS Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: High Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: W.Price@electronic-alchemy.co.uk Building C++ code which includes produces the following errors: /usr/include/xfs/swab.h: In function `const __u64 __fswab64(long long unsigned int)': /usr/include/xfs/swab.h:144: error: ISO C++ forbids braced-groups within expressions /usr/include/xfs/swab.h:144: error: ISO C++ forbids braced-groups within expressions /usr/include/xfs/swab.h: In function `__u64 __swab64p(__u64*)': /usr/include/xfs/swab.h:149: error: ISO C++ forbids braced-groups within expressions /usr/include/xfs/swab.h:149: error: ISO C++ forbids braced-groups within expressions /usr/include/xfs/swab.h: In function `void __swab64s(__u64*)': /usr/include/xfs/swab.h:153: error: ISO C++ forbids braced-groups within expressions /usr/include/xfs/swab.h:153: error: ISO C++ forbids braced-groups within expressions This is using xfsprogs-2.6.3 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 17 02:32:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Mar 2004 02:32:46 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2HAWiKO012273 for ; Wed, 17 Mar 2004 02:32:44 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2HAWi86012272 for linux-xfs@oss.sgi.com; Wed, 17 Mar 2004 02:32:44 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2HAWhKQ012258 for ; Wed, 17 Mar 2004 02:32:43 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2H9a48S006999; Wed, 17 Mar 2004 01:36:04 -0800 Date: Wed, 17 Mar 2004 01:36:04 -0800 Message-Id: <200403170936.i2H9a48S006999@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 316] C++ compiler errors/warnings X-Bugzilla-Reason: AssignedTo X-archive-position: 2484 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 574 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=316 ------- Additional Comments From W.Price@electronic-alchemy.co.uk 2004-17-03 01:36 PDT ------- This error occurs both on RH7.3 using gcc2.96 and on Fedora usign gcc3.2.2. The compiler options are: -g -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wall -Wno-sign-compare -Wunused -Wno-long-long -pedantic -DQT_THREAD_SUPPORT -DQT_CLEAN_NAMESPACE ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 17 03:32:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Mar 2004 03:32:48 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2HBWjKO016096 for ; Wed, 17 Mar 2004 03:32:45 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2HBWj9r016095 for linux-xfs@oss.sgi.com; Wed, 17 Mar 2004 03:32:45 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2HBWhKQ016081 for ; Wed, 17 Mar 2004 03:32:43 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2HBMRc5015390; Wed, 17 Mar 2004 03:22:27 -0800 Date: Wed, 17 Mar 2004 03:22:27 -0800 Message-Id: <200403171122.i2HBMRc5015390@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 316] C++ compiler errors/warnings X-Bugzilla-Reason: AssignedTo X-archive-position: 2485 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 315 Lines: 14 http://oss.sgi.com/bugzilla/show_bug.cgi?id=316 ------- Additional Comments From W.Price@electronic-alchemy.co.uk 2004-17-03 03:22 PDT ------- That should have read 'gcc 3.3.2' on Fedora. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 17 08:11:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Mar 2004 08:11:06 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2HGB3KO005415 for ; Wed, 17 Mar 2004 08:11:03 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2HG3X4Y031108 for ; Wed, 17 Mar 2004 10:03:33 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2HG3WKe35557393 for ; Wed, 17 Mar 2004 10:03:32 -0600 (CST) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i2HG3VXa1775462; Wed, 17 Mar 2004 10:03:31 -0600 (CST) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id i2HG2w8J001312; Wed, 17 Mar 2004 10:02:59 -0600 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id i2FMCEig024697; Mon, 15 Mar 2004 16:12:14 -0600 Date: Mon, 15 Mar 2004 16:12:14 -0600 From: Eric Sandeen Message-Id: <200403152212.i2FMCEig024697@penguin.americas.sgi.com> Subject: TAKE 910764 - X-archive-position: 2486 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 580 Lines: 23 Date: Mon Mar 15 14:10:59 PST 2004 Workarea: penguin.americas.sgi.com:/src/eric/xfs-trees/xfs-GUT Inspected by: hch The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:168484a linux-2.6/xfs_aops.c - 1.66 - Use pgoff_t type for page indices, and remove some other type confusion linux-2.4/xfs_linux.h - 1.130 - define pgoff_t for 2.6 compat linux-2.4/xfs_aops.c - 1.75 linux-2.6/xfs_buf.c - 1.157 linux-2.4/xfs_buf.c - 1.179 - Use pgoff_t type for page indices, and remove some other type confusion From owner-linux-xfs@oss.sgi.com Wed Mar 17 13:32:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Mar 2004 13:32:48 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2HLWkKO023789 for ; Wed, 17 Mar 2004 13:32:46 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2HLWkJG023788 for linux-xfs@oss.sgi.com; Wed, 17 Mar 2004 13:32:46 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2HLWjKQ023774 for ; Wed, 17 Mar 2004 13:32:45 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2HKYlOv022496; Wed, 17 Mar 2004 12:34:47 -0800 Date: Wed, 17 Mar 2004 12:34:47 -0800 Message-Id: <200403172034.i2HKYlOv022496@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 317] New: Kernel error messages using XFS X-Bugzilla-Reason: AssignedTo X-archive-position: 2487 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 4885 Lines: 106 http://oss.sgi.com/bugzilla/show_bug.cgi?id=317 Summary: Kernel error messages using XFS Product: Linux XFS Version: 1.3.x Platform: IA32 OS/Version: Linux Status: NEW Severity: major Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: greg@wildbrain.com I am using the version of XFS as shipped in the stock 2.4.25 kernel with RedHat 9. I created a fresh 1.9TB filesystem with: % mkfs -t xfs -f -i size=512 /dev/md0 meta-data=/exports isize=512 agcount=32, agsize=15319808 blks = sectsz=512 data = bsize=4096 blocks=490231296, imaxpct=25 = sunit=128 swidth=512 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=2097152 blocks=0, rtextents=0 I then proceeded to copy 170 GB of data to the filesystem using rsync. After approximately 160 GB had finished copying, performance slowed greatly and these kernel messages began (there were a lot of them.) Mar 16 23:52:36 violet kernel: Filesystem "md(9,0)": XFS internal error xfs_btree_check_sblock at line 342 of file xfs_btree.c. Caller 0xf8995cfc Mar 16 23:52:36 violet kernel: cf78785c f89b02a5 f8a0ceab 00000001 f712a400 f8a0ce6e 00000156 f8995cfc Mar 16 23:52:36 violet kernel: 00000000 c8e5c000 d9be6f70 00000000 f8995cfc d9be6f70 c8e5c000 00000000 Mar 16 23:52:36 violet kernel: e4448c80 00000000 cf7878d0 00000002 c0221929>] [] [] [] Mar 16 23:52:36 violet kernel: [] [] [] [] [] [] Mar 16 23:52:36 violet kernel: [] [] [] [] [] [] Mar 16 23:52:36 violet kernel: [] [] [] Mar 16 23:52:36 violet kernel: Filesystem "md(9,0)": XFS internal error xfs_btree_check_sblock at line 342 of file xfs_btree.c. Caller 0xf8995cfc Mar 16 23:52:36 violet kernel: cf78785c f89b02a5 f8a0ceab 00000001 f712a400 f8a0ce6e 00000156 f8995cfc Mar 16 23:52:36 violet kernel: 00000000 c8e5c000 d9be6f70 00000000 f8995cfc d9be6f70 c8e5c000 00000000 Mar 16 23:52:36 violet kernel: e4448c80 00000000 cf7878d0 00000002 f8a01ff8 f2c77010 00000000 00000002 Mar 16 23:52:36 violet kernel: Call Trace: [] [] [] [] [] Mar 16 23:52:36 violet kernel: [] [] [] [] [] [] Mar 16 23:52:36 violet kernel: [] [] [] [] [] [] Mar 16 23:52:36 violet kernel: [] [] [] [] [] [] Mar 16 23:52:36 violet kernel: [] [] [] [] [] [] Mar 16 23:52:36 violet kernel: [] [] [] [] [] [] Mar 16 23:52:36 violet kernel: [] [] [] Mar 16 23:52:36 violet kernel: Filesystem "md(9,0)": XFS internal error xfs_btree_check_sblock at line 342 of file xfs_btree.c. Caller 0xf8995cfc Mar 16 23:52:36 violet kernel: cf78785c f89b02a5 f8a0ceab 00000001 f712a400 f8a0ce6e 00000156 f8995cfc Mar 16 23:52:36 violet kernel: 00000000 c8e5c000 d9be6f70 00000000 f8995cfc d9be6f70 c8e5c000 00000000 Mar 16 23:52:36 violet kernel: e4448c80 00000000 cf7878d0 00000002 f8a01ff8 f2c77010 00000000 00000002 Mar 16 23:52:36 violet kernel: Call Trace: [] [] [] [] [] Mar 16 23:52:36 violet kernel: [] [] [] [] [] [] Mar 16 23:52:36 violet kernel: [] [] [] [] [] [] Mar 16 23:52:36 violet kernel: [] [] [] [] [] [] Mar 16 23:52:36 violet kernel: [] [] [] [] [] [] Mar 16 23:52:36 violet kernel: [] [] [] [] [] [] Mar 16 23:52:36 violet kernel: [] [] [] etc. A xfs_check showed the same error on many tens-of-thousands of inodes (very sorry, forgot to save it). I ran xfs_repair, and all seems to be working again. This system did not show any problems like this through a couple of months of rigorous stress testing. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 17 13:41:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Mar 2004 13:41:45 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2HLfdKO024381 for ; Wed, 17 Mar 2004 13:41:39 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2HNhXgq018303 for ; Wed, 17 Mar 2004 15:43:33 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2HLfYKe35525670 for ; Wed, 17 Mar 2004 15:41:34 -0600 (CST) Received: from zhadum.americas.sgi.com (zhadum.americas.sgi.com [128.162.233.43]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i2HLfXXa1801580 for ; Wed, 17 Mar 2004 15:41:33 -0600 (CST) Received: from zhadum.americas.sgi.com by zhadum.americas.sgi.com (SGI-8.12.5/SGI-client-1.7) via ESMTP id i2HLfXBh143713; Wed, 17 Mar 2004 15:41:33 -0600 (CST) Received: (from overby@localhost) by zhadum.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2HLfXck143844; Wed, 17 Mar 2004 15:41:33 -0600 (CST) Date: Wed, 17 Mar 2004 15:41:33 -0600 (CST) Message-Id: <200403172141.i2HLfXck143844@zhadum.americas.sgi.com> From: Glen Overby To: linux-xfs@oss.sgi.com Reply-To: xfs-linux@oss.sgi.com Subject: Filesystem "sd(8,33)": xfs_log_write: reservation ran out. Need to up reservatio X-archive-position: 2488 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: overby@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1020 Lines: 29 I've fixed the transaction space reservation that caues filesystem shutdowns when running with inode deletion code (the "noikeep" mount option). The fix in the top-of-tree XFS code, which should be on oss.sgi.com now. I have not turned inode deletion on by default, but I am interested in having people give it a try (especially those who had problems with it when it was on by default). Glen Overby ========================== ADDITIONAL INFORMATION (TAKE) From: glen overby Date: Mar 17 2004 08:04:06AM [BugWorks mailnews processor v1.4.7] ========================== Date: Tue Mar 16 16:52:31 PST 2004 Workarea: penguin.americas.sgi.com:/data/clink/a23/overby/l-2.4 Inspected by: sandeen,cattelan The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:168597a fs/xfs/xfs_trans.h - 1.124 - Add space for inode and allocation btrees to ITRUNCATE log reservation Add XFS_ALLOCFREE_LOG_RES to IFREE log reservation. From owner-linux-xfs@oss.sgi.com Wed Mar 17 14:32:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Mar 2004 14:32:58 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2HMWsKO027432 for ; Wed, 17 Mar 2004 14:32:54 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2HMWsTE027430 for linux-xfs@oss.sgi.com; Wed, 17 Mar 2004 14:32:54 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2HMWjKU027394 for ; Wed, 17 Mar 2004 14:32:52 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2HLiU8t024850; Wed, 17 Mar 2004 13:44:30 -0800 Date: Wed, 17 Mar 2004 13:44:30 -0800 Message-Id: <200403172144.i2HLiU8t024850@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 284] Log reservation runs out with bonnie++ X-Bugzilla-Reason: AssignedTo X-archive-position: 2489 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 615 Lines: 24 http://oss.sgi.com/bugzilla/show_bug.cgi?id=284 overby@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From overby@sgi.com 2004-17-03 13:44 PDT ------- Fixed by fixing the transaction space reservation calculation. (bug 313 is a dup of this) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 17 14:32:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Mar 2004 14:33:03 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2HMWsKO027431 for ; Wed, 17 Mar 2004 14:32:54 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2HMWsgP027429 for linux-xfs@oss.sgi.com; Wed, 17 Mar 2004 14:32:54 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2HMWjKW027394 for ; Wed, 17 Mar 2004 14:32:52 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2HLgNIh024527; Wed, 17 Mar 2004 13:42:23 -0800 Date: Wed, 17 Mar 2004 13:42:23 -0800 Message-Id: <200403172142.i2HLgNIh024527@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 313] xfs_log_write: reservation ran out. Need to up reservation X-Bugzilla-Reason: AssignedTo X-archive-position: 2490 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 597 Lines: 23 http://oss.sgi.com/bugzilla/show_bug.cgi?id=313 overby@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From overby@sgi.com 2004-17-03 13:42 PDT ------- Fixed by fixing the transaction space reservation calculation. PV 909844 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 17 16:41:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Mar 2004 16:41:07 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2I0f3KO002105 for ; Wed, 17 Mar 2004 16:41:03 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2I0ekf5021393 for ; Wed, 17 Mar 2004 18:40:46 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2I0ekKe35478602 for ; Wed, 17 Mar 2004 18:40:46 -0600 (CST) Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i2I0ejXa1706699; Wed, 17 Mar 2004 18:40:45 -0600 (CST) Received: by naboo.americas.sgi.com (Postfix, from userid 29039) id 021DA8CD10E; Wed, 17 Mar 2004 18:40:44 -0600 (CST) Subject: PARTIAL TAKE 909556 - add call to move buffers to clean list Message-Id: <20040318004044.021DA8CD10E@naboo.americas.sgi.com> Date: Wed, 17 Mar 2004 18:40:44 -0600 (CST) From: cattelan@sgi.com (Russell Cattelan) To: undisclosed-recipients:;;;;@sgi.com;;; X-archive-position: 2491 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 497 Lines: 16 We sould start moving this around to all the nessesary trees. Date: Wed Mar 17 16:38:35 PST 2004 Workarea: naboo.americas.sgi.com:/go/space/XFS/xfs-linux-p Inspected by: steiner@sgi.com,nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:168680a linux-2.4/xfs_aops.c - 1.76 - Add a call to refile_buffer since xfs was not being good buffer citizens and was leaving clean buffers on the dirty buffer list. From owner-linux-xfs@oss.sgi.com Wed Mar 17 19:39:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Mar 2004 19:39:45 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2I3dhKO007887 for ; Wed, 17 Mar 2004 19:39:43 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2I3UAf5029684 for ; Wed, 17 Mar 2004 21:30:10 -0600 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2I3U9Ke35530358 for ; Wed, 17 Mar 2004 21:30:10 -0600 (CST) Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i2I3U8Ga412229; Wed, 17 Mar 2004 21:30:09 -0600 (CST) Received: (from lmc@localhost) by attica.americas.sgi.com (8.11.6/8.11.6/erikj-RedHat-7.2-Eagan) id i2I3U8I15548; Wed, 17 Mar 2004 21:30:08 -0600 Date: Wed, 17 Mar 2004 21:30:08 -0600 From: Laurie Costello Message-Id: <200403180330.i2I3U8I15548@attica.americas.sgi.com> To: linux-xfs@oss.sgi.com Cc: sgi.bugs.snlinux@fido.engr.sgi.com Subject: TAKE 909519 - X-archive-position: 2492 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lmc@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 352 Lines: 13 Date: Wed Mar 17 19:29:04 PST 2004 Workarea: attica.americas.sgi.com:/data/lwork/attica1/lmc/lbs3.0_nochroot Inspected by: rls The following file(s) were checked into: bonnie.engr.sgi.com:/proj/sgilinux/lbs3.0/isms Modid: lbs3.0:xvm-kern:168690a cluster/xvm-kern/xvm_garbage.c - 1.15 - Don't use xvm_spl_t as its not yet defined. Use int. From owner-linux-xfs@oss.sgi.com Wed Mar 17 22:45:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Mar 2004 22:45:11 -0800 (PST) Received: from rrzd1.rz.uni-regensburg.de (rrzd1.rz.uni-regensburg.de [132.199.1.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2I6j3KO015554 for ; Wed, 17 Mar 2004 22:45:06 -0800 Received: from rrzd1 (rrzd1 [127.0.0.1]) by rrzd1.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with ESMTP id i2I6j2Gj020833; Thu, 18 Mar 2004 07:45:02 +0100 Received: from rx3227.cip.uni-regensburg.de ([132.199.237.32]) by rrzd1 (MailMonitor for SMTP v1.2.2 ) ; Thu, 18 Mar 2004 07:45:02 +0100 (CET) Subject: Re: Filesystem "sd(8,33)": xfs_log_write: reservation ran out. Need to up reservatio From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: Glen Overby Cc: linux-xfs@oss.sgi.com In-Reply-To: <200403172141.i2HLfXck143844@zhadum.americas.sgi.com> References: <200403172141.i2HLfXck143844@zhadum.americas.sgi.com> Content-type: text/plain Message-Id: <1079592301.1830.6.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 18 Mar 2004 07:45:01 +0100 Content-Transfer-Encoding: 8bit X-archive-position: 2493 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 835 Lines: 23 On Wed, 2004-03-17 at 22:41, Glen Overby wrote: > I've fixed the transaction space reservation that caues filesystem > shutdowns when running with inode deletion code (the "noikeep" mount > option). The fix in the top-of-tree XFS code, which should be on > oss.sgi.com now. I have not turned inode deletion on by default, but > I am interested in having people give it a try (especially those who > had problems with it when it was on by default). > Well Done, Glen ! Back in the 2.4.22/23 (CVS) days, I had a machine which would fail 100% reproducible the bonnie++ test runs described in #284. Even plain 2.4.25 would fail them, if the 'noikeep' option was used at mount-time. With latest CVS code from oss (I've verified, that xfs_trans.h is revision 1.124) the bonnie++ tests complete without an errror. thanks. Christian From owner-linux-xfs@oss.sgi.com Wed Mar 17 22:55:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Mar 2004 22:55:35 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2I6tWKO016085 for ; Wed, 17 Mar 2004 22:55:33 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2I6pqQe029526 for ; Thu, 18 Mar 2004 00:51:54 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2I6pfAL10477152; Thu, 18 Mar 2004 17:51:41 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2I6peZX10457579; Thu, 18 Mar 2004 17:51:40 +1100 (EST) Date: Thu, 18 Mar 2004 17:51:40 +1100 (EST) From: Nathan Scott Message-Id: <200403180651.i2I6peZX10457579@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 911435 - fix debug builds X-archive-position: 2494 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 352 Lines: 13 Fix debug builds - need sb_features2 details in endian translation code. Date: Wed Mar 17 22:50:44 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-xfs-linux Inspected by: overby@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:168693a xfs_mount.c - 1.341 From owner-linux-xfs@oss.sgi.com Thu Mar 18 00:32:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Mar 2004 00:32:52 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2I8WoKO022016 for ; Thu, 18 Mar 2004 00:32:50 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2I8Wo5r022015 for linux-xfs@oss.sgi.com; Thu, 18 Mar 2004 00:32:50 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2I8WlKQ022000 for ; Thu, 18 Mar 2004 00:32:48 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2I7gsUh018069; Wed, 17 Mar 2004 23:42:54 -0800 Date: Wed, 17 Mar 2004 23:42:54 -0800 Message-Id: <200403180742.i2I7gsUh018069@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 311] ioctl hang in 2.6.x kernels with quota support X-Bugzilla-Reason: AssignedTo X-archive-position: 2495 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 937 Lines: 24 http://oss.sgi.com/bugzilla/show_bug.cgi?id=311 ------- Additional Comments From steven.wilton@team.eftel.com 2004-17-03 23:42 PDT ------- I have managed to replicate the problem on a 2.6.4 kernel on our backup storage server. I log into the server an run 2x copies of "quot" and a copy of xfs_fsr, and at least one of the processes seems to hang. What I am having trouble doing is getting kdb to work. I'm assuming that the debugging options that are in the standard 2.6.4 kernel work, but I can't figure out what I need to do to enter kdb, or how to use it when I am there. Can you please point me at some documentation on how to use kdb, and let me know if there is a patch that I need to apply to 2.6.4 to get it working. I should be able to provide the necessary info if I can get kdb working. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 18 11:15:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Mar 2004 11:15:28 -0800 (PST) Received: from moria.linuxis.net (moria.linuxis.net [209.237.231.67]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2IJFOKO006025 for ; Thu, 18 Mar 2004 11:15:24 -0800 Received: (qmail 18316 invoked from network); 18 Mar 2004 19:02:31 -0000 Received: from unknown (HELO shoshana.dnsalias.org) (67.173.135.227) by 209.237.231.80 with SMTP; 18 Mar 2004 19:02:31 -0000 Received: (qmail 1634 invoked by uid 501); 18 Mar 2004 19:15:45 -0000 Date: Thu, 18 Mar 2004 13:15:23 -0600 From: John Palkovic To: linux-xfs@oss.sgi.com Subject: Re: 2.6.4 can't mount root xfs Message-ID: <20040318191523.GA1592@palkovic.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20040316193914.GA1564@palkovic.org> <20040316194423.A4914@infradead.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040316194423.A4914@infradead.org> User-Agent: Mutt/1.5.5.1+cvs20040105i Content-Transfer-Encoding: 8bit X-archive-position: 2496 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scientist@palkovic.org Precedence: bulk X-list: linux-xfs Content-Length: 1285 Lines: 30 On Tue, Mar 16, 2004 at 07:44:01PM +0000, Christoph Hellwig wrote: > This is not a XFS issue, the kernel doesn't even get far enough to call > the XFS mount code. ... Here is what I can report about this unresolved issue. CONFIG_DEVFS_FS is not set. The system has two hard drives, one SCSI, the other IDE. I normally boot from the SCSI drive and use the IDE for backup. Each drive is formatted with /boot, swap, /, /usr, and /home partitions. The box fails to boot 2.6.4 from the SCSI drive with an ext2 /boot and XFS /, /usr, and /home, as I detailed previously. I am using the grub bootloader, if it matters. Just for grins, I reformatted /, /boot, and /usr on the IDE drive as ext3 partitions and built a new 2.6.4 kernel with ext3 support. This 2.6.4 kernel boots cleanly from the IDE drive. The exact same kernel panics and fails to mount the XFS root from the SCSI drive. Yet you're telling me this is not an XFS issue. Is grub hosing me here? The only other datum I can add is that a back-trace from magic sysrq tells me it's panicking in mount_block_root, but I suspect you already knew that. regards, -John -- "The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell From owner-linux-xfs@oss.sgi.com Thu Mar 18 12:57:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Mar 2004 12:57:17 -0800 (PST) Received: from mx13.mail.ru (mx13.mail.ru [194.67.23.56]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2IKvCKO012627 for ; Thu, 18 Mar 2004 12:57:13 -0800 Received: from [62.205.183.218] (port=3050 helo=home-pc) by mx13.mail.ru with esmtp id 1B44ZY-000EgW-00 for linux-xfs@oss.sgi.com; Thu, 18 Mar 2004 23:57:01 +0300 Date: Thu, 18 Mar 2004 23:56:52 +0300 From: Alexander Ivanov X-Mailer: The Bat! (v1.53d) Reply-To: Alexander Ivanov X-Priority: 3 (Normal) Message-ID: <24092781.20040318235652@mail.ru> To: linux-xfs@oss.sgi.com Subject: XFS on Promise RAID5 problems MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Spam: Not detected X-archive-position: 2497 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: an_ivanov@mail.ru Precedence: bulk X-list: linux-xfs Content-Length: 4242 Lines: 146 Hello, XFS gurus! I used XFS on Linux fileserver (RedHat 7.3 with 2.4.18 kernel from sgi.com, XFS v1.1) more then 1 year with no problems. This week I upgraded to hardware RAID Promise FastTrak SX4000 (3x80G IDE drives in RAID5). XFS is on top of /dev/sda. When copying files to this RAID XFS over the network kernel frequently logs error messages like this: Mar 18 17:45:30 server kernel: xfs_btree_check_sblock: Not OK: Mar 18 17:45:30 server kernel: magic 0xaba7e24f level 1736 numrecs 39369 leftsib -593020325 rightsib 924741638 Checking /dev/sda produce this results: #xfs_check /dev/sda bad magic # 0x9e32e249 in btbno block 37/1 bad magic # 0xaba7e24f in btcnt block 37/2 bad magic # 0x47491577 in inobt block 37/3 agf_freeblks 265180, counted 0 in ag 37 agf_longest 265180, counted 0 in ag 37 When I ran xfs_repair -n (no actual repair - just messages): #xfs_repair -n /dev/sda Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... bad magic # 0x9e32e249 in btbno block 37/1 expected level 0 got 42641 in btbno block 37/1 bad magic # 0xaba7e24f in btcnt block 37/2 expected level 0 got 1736 in btcnt block 37/2 bad magic # 0x47491577 in inobt block 37/3 expected level 0 got 58941 in inobt block 37/3 dubious inode btree block header 37/3 badly aligned inode rec (starting inode = 4251520898) bad starting inode # (4251520898 (0x25 0xdd690f82)) in ino rec, skipping rec badly aligned inode rec (starting inode = 3184326952) bad starting inode # (3184326952 (0x25 0xb8ccf928)) in ino rec, skipping rec badly aligned inode rec (starting inode = 3981325857) bad starting inode # (3981325857 (0x25 0xe84e3621)) in ino rec, skipping rec badly aligned inode rec (starting inode = 1706848453) . . about 250 these errors.... . badly aligned inode rec (starting inode = 3045813498) bad starting inode # (3045813498 (0x25 0xb58b6cfa)) in ino rec, skipping rec - found root inode chunk - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... No modify flag set, skipping phase 5 Inode allocation btrees are too corrupted, skipping phases 6 and 7 No modify flag set, skipping filesystem flush and exiting. ------------------------------ Is this a hardware problem, bug in FastTrak driver or it is XFS-related? Must I run xfs_repair in this situation? Recommendations to correct this problems? Thank you for assistance. -- Alexander mailto:an_ivanov@mail.ru From owner-linux-xfs@oss.sgi.com Thu Mar 18 13:32:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Mar 2004 13:33:03 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2ILWpKO013840 for ; Thu, 18 Mar 2004 13:32:51 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2ILWpY3013839 for linux-xfs@oss.sgi.com; Thu, 18 Mar 2004 13:32:51 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2ILWnKQ013824 for ; Thu, 18 Mar 2004 13:32:50 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2ILHtUg013502; Thu, 18 Mar 2004 13:17:55 -0800 Date: Thu, 18 Mar 2004 13:17:55 -0800 Message-Id: <200403182117.i2ILHtUg013502@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 318] New: kernel BUG at fs/xfs/support/debug.c:106 X-Bugzilla-Reason: AssignedTo X-archive-position: 2498 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 6343 Lines: 133 http://oss.sgi.com/bugzilla/show_bug.cgi?id=318 Summary: kernel BUG at fs/xfs/support/debug.c:106 Product: Linux XFS Version: 1.3.x Platform: IA32 OS/Version: Linux Status: NEW Severity: major Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: vb-sgibugzilla@tiguidoo.com The server is a dual Athlon server running on a Tyan board. Disk subsystem is composed of multiple IDE drives using Linux-based software RAID. I use the XFS version included in 2.6.4 Linux Kernel : Linux version 2.6.4 (root@gabriela) (gcc version 2.95.4 20011002 (Debian prerelease)) #1 SMP Mon Mar 15 16:53:58 EST 2004 OS is Debian 3.0 with all the security updates. System is running a custom C data crunching application working on big files 100MB-10000MB files and a kernel-based NFS server. I used 2.4.x kernel and ext3 on the same machine without ANY kernel panic for 1 year. I changed to XFS and 2.6.4 kernel in hope for higher performance since XFS is known to be really good at playing with big files. After 10 days of uptime, the server died during an intensive disk IO operation, but was still answering to network pings. Here is the last output from the machine : Mar 17 22:38:01 gabriela kernel: ------------[ cut here ]------------ Mar 17 22:38:01 gabriela kernel: kernel BUG at fs/xfs/support/debug.c:106! Mar 17 22:38:01 gabriela kernel: invalid operand: 0000 [#1] Mar 17 22:38:01 gabriela kernel: SMP Mar 17 22:38:01 gabriela kernel: CPU: 1 Mar 17 22:38:01 gabriela kernel: EIP: 0060:[_end+945977111/1069909120] Not tainted Mar 17 22:38:01 gabriela kernel: EFLAGS: 00010246 Mar 17 22:38:01 gabriela kernel: EIP is at cmn_err+0x97/0xb0 [xfs] Mar 17 22:38:01 gabriela kernel: eax: 00000040 ebx: 00000293 ecx: 000008fc edx: c02ec264 Mar 17 22:38:01 gabriela kernel: esi: f89d6807 edi: f89e6d3e ebp: 00000000 esp: c4cf5a74 Mar 17 22:38:01 gabriela kernel: ds: 007b es: 007b ss: 0068 Mar 17 22:38:01 gabriela kernel: Process nfsd (pid: 3410, threadinfo=c4cf4000 task=f288b980) Mar 17 22:38:01 gabriela kernel: Stack: c037eca0 f6dff734 c4cf4000 f2e40d24 dd2c0660 f899f823 00000000 f89d1620 Mar 17 22:38:01 gabriela kernel: cc4c1680 dd2c0640 dd2c0660 dd2c0640 c4cf4000 00000008 f6dff738 ee4c2550 Mar 17 22:38:01 gabriela kernel: f899fc4c dd2c0640 f2e40c00 00000000 047578ce 00000000 00000008 c4cf5b24 Mar 17 22:38:01 gabriela kernel: Call Trace: Mar 17 22:38:01 gabriela kernel: [_end+945790115/1069909120] xfs_iget_core+0x163/0x500 [xfs] Mar 17 22:38:01 gabriela kernel: [_end+945791180/1069909120] xfs_iget+0x8c/0x160 [xfs] Mar 17 22:38:01 gabriela kernel: [_end+945906548/1069909120] xfs_vget+0x44/0xc0 [xfs] Mar 17 22:38:01 gabriela kernel: [_end+945974213/1069909120] vfs_vget+0x25/0x30 [xfs] Mar 17 22:38:01 gabriela kernel: [_end+945972696/1069909120] linvfs_get_dentry+0x48/0x90 [xfs] Mar 17 22:38:01 gabriela kernel: [find_exported_dentry+61/1712] find_exported_dentry+0x3d/0x6b0 Mar 17 22:38:01 gabriela kernel: [nfsd_acceptable+207/224] nfsd_acceptable+0xcf/0xe0 Mar 17 22:38:01 gabriela kernel: [find_exported_dentry+154/1712] find_exported_dentry+0x9a/0x6b0 Mar 17 22:38:01 gabriela kernel: [udp_queue_rcv_skb+420/544] udp_queue_rcv_skb+0x1a4/0x220 Mar 17 22:38:01 gabriela kernel: [udp_rcv+338/848] udp_rcv+0x152/0x350 Mar 17 22:38:01 gabriela kernel: [ip_local_deliver+164/336] ip_local_deliver+0xa4/0x150 Mar 17 22:38:01 gabriela kernel: [_end+945675809/1069909120] xfs_bmbt_get_state+0x21/0x30 [xfs] Mar 17 22:38:01 gabriela kernel: [do_gettimeofday+30/192] do_gettimeofday+0x1e/0xc0 Mar 17 22:38:01 gabriela kernel: [alloc_skb+60/224] alloc_skb+0x3c/0xe0 Mar 17 22:38:01 gabriela kernel: [boomerang_rx+799/1056] boomerang_rx+0x31f/0x420 Mar 17 22:38:01 gabriela kernel: [boomerang_interrupt+303/1008] boomerang_interrupt+0x12f/0x3f0 Mar 17 22:38:02 gabriela kernel: [sock_alloc_send_skb+28/48] sock_alloc_send_skb+0x1c/0x30 Mar 17 22:38:02 gabriela kernel: [ip_defrag+236/384] ip_defrag+0xec/0x180 Mar 17 22:38:02 gabriela kernel: [ip_local_deliver+27/336] ip_local_deliver+0x1b/0x150 Mar 17 22:38:02 gabriela kernel: [ip_rcv+874/1036] ip_rcv+0x36a/0x40c Mar 17 22:38:02 gabriela kernel: [netif_receive_skb+305/368] netif_receive_skb+0x131/0x170 Mar 17 22:38:02 gabriela kernel: [process_backlog+137/288] process_backlog+0x89/0x120 Mar 17 22:38:02 gabriela kernel: [boomerang_start_xmit+634/784] boomerang_start_xmit+0x27a/0x310 Mar 17 22:38:02 gabriela kernel: [groups_free+59/80] groups_free+0x3b/0x50 Mar 17 22:38:02 gabriela kernel: [export_decode_fh+102/110] export_decode_fh+0x66/0x6e Mar 17 22:38:02 gabriela kernel: [nfsd_acceptable+0/224] nfsd_acceptable+0x0/0xe0 Mar 17 22:38:02 gabriela kernel: [fh_verify+916/1360] fh_verify+0x394/0x550 Mar 17 22:38:02 gabriela kernel: [nfsd_acceptable+0/224] nfsd_acceptable+0x0/0xe0 Mar 17 22:38:02 gabriela kernel: [nfsd_open+44/352] nfsd_open+0x2c/0x160 Mar 17 22:38:02 gabriela kernel: [nfsd_write+50/752] nfsd_write+0x32/0x2f0 Mar 17 22:38:02 gabriela kernel: [do_softirq+108/208] do_softirq+0x6c/0xd0 Mar 17 22:38:02 gabriela kernel: [smp_apic_timer_interrupt+323/336] smp_apic_timer_interrupt+0x143/0x150 Mar 17 22:38:02 gabriela kernel: [apic_timer_interrupt+26/32] apic_timer_interrupt+0x1a/0x20 Mar 17 22:38:02 gabriela kernel: [kfree+89/112] kfree+0x59/0x70 Mar 17 22:38:02 gabriela kernel: [kfree_skbmem+23/32] kfree_skbmem+0x17/0x20 Mar 17 22:38:02 gabriela kernel: [svcauth_unix_accept+540/688] svcauth_unix_accept+0x21c/0x2b0 Mar 17 22:38:03 gabriela kernel: [nfsd_proc_write+168/176] nfsd_proc_write+0xa8/0xb0 Mar 17 22:38:03 gabriela kernel: [nfsd_dispatch+225/403] nfsd_dispatch+0xe1/0x193 Mar 17 22:38:03 gabriela kernel: [svc_process+875/1512] svc_process+0x36b/0x5e8 Mar 17 22:38:03 gabriela kernel: [nfsd+492/864] nfsd+0x1ec/0x360 Mar 17 22:38:03 gabriela kernel: [nfsd+0/864] nfsd+0x0/0x360 Mar 17 22:38:03 gabriela kernel: [kernel_thread_helper+5/20] kernel_thread_helper+0x5/0x14 Mar 17 22:38:03 gabriela kernel: Mar 17 22:38:03 gabriela kernel: Code: 0f 0b 6a 00 ee 67 9d f8 90 5b 5e 5f 5d 59 c3 8d 76 00 8d bc ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 18 13:38:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Mar 2004 13:38:33 -0800 (PST) Received: from mail.slb.com (eurmta01.london.eur.slb.com [134.32.26.55]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2ILcRKO014330 for ; Thu, 18 Mar 2004 13:38:29 -0800 Received: from conversion-daemon.eurmta01.london.eur.slb.com by eurmta01.london.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) id <0HUS00G01IW1HI@eurmta01.london.eur.slb.com> for linux-xfs@oss.sgi.com; Thu, 18 Mar 2004 21:26:49 +0000 (GMT) Received: from stavanger.westerngeco.slb.com (wgmail9.stavanger.eur.slb.com [134.32.72.36]) by eurmta01.london.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HUS00H62JJ4MD@eurmta01.london.eur.slb.com> for linux-xfs@oss.sgi.com; Thu, 18 Mar 2004 21:25:53 +0000 (GMT) Received: from GSTJ2W (localhost [127.0.0.1]) by stavanger.westerngeco.slb.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id i2ILKeF05777 for ; Thu, 18 Mar 2004 22:20:40 +0100 (MET) Date: Thu, 18 Mar 2004 22:25:49 +0100 From: marat Subject: Re: [Bug 198] was it solved ? In-reply-to: <1078337183.12279.8.camel@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com Message-id: <200403041411.54696.marat@stavanger.westerngeco.slb.com> Organization: westerngeco MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit User-Agent: KMail/1.4.1 References: <200403031505.37729.marat@stavanger.westerngeco.slb.com> <1078337183.12279.8.camel@naboo.americas.sgi.com> X-archive-position: 2499 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: marat@stavanger.westerngeco.slb.com Precedence: bulk X-list: linux-xfs Content-Length: 1868 Lines: 72 Hi Russell, > This one is eluding us, we have has many false starts on this. The script "test programm for local corruption on linux xfs" attached to Bug 198 , is it valid tool to indicate a problem ? Have somebody tried to run this script with no problems ? I have tried this script on : 1. RedHat 7.3, kernel 2.4.20 smp, xfs 1.3.0 ( without LVM ) 2. RedHat 9.0, kernel 2.4.20-19.9 smp , xfs 1.3.0 ( without LVM ) and , it shows the same problem. Best Regards, Marat On Wednesday 03 March 2004 19:06, Russell Cattelan wrote: > > On Wed, 2004-03-03 at 08:05, marat wrote: > > Hi experts, > > > > I have a problem with corrupted files on xfs+lvm+nfs system ( Kernel > > 2.4.20 xfs version1.3.0 . ) > > > > The problem is looks similar to BUG 198 ( > > http://oss.sgi.com/bugzilla/show_bug.cgi?id=198 ). I have tried to to run > > "test programm for local corruption on linux xfs" attached to Bug 198. > > And it shows the same problem. Here is part of log file : > > > > Run 1 @Wed Mar 3 12:07:52 CET 2004 > > Doublewrite: length 1000MB, chunks 16384 bytes, mark 0x02 > > Graceful exit > > Error!! > > Error: offset 839155712, data 0x3333333333333333 expected > > 0x0000000032048000 > > > > And another one : > > > > Run 1 @Wed Mar 3 12:54:48 CET 2004 > > Doublewrite: length 1000MB, chunks 16384 bytes, mark 0x02 > > Graceful exit > > OK > > File size 1048576000 > > Run 2 @Wed Mar 3 13:00:16 CET 2004 > > Doublewrite: length 1000MB, chunks 16384 bytes, mark 0x02 > > Graceful exit > > OK > > File size 1048576000 > > Run 3 @Wed Mar 3 13:07:04 CET 2004 > > Doublewrite: length 1000MB, chunks 16384 bytes, mark 0x02 > > Graceful exit > > Error!! > > Error: offset 988577792, data 0x010300002cf50000 expected > > 0x000000003aec8000 > > > > > > > > Could anybody tell how to fix it ? > > > > > > thanks in Advance, > > > > Marat Mukhitov From owner-linux-xfs@oss.sgi.com Thu Mar 18 14:43:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Mar 2004 14:43:03 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2IMgrKO017662 for ; Thu, 18 Mar 2004 14:42:59 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2IMgl9x550352 for ; Thu, 18 Mar 2004 17:42:47 -0500 Received: from d03nm131.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2IMgcke373172 for ; Thu, 18 Mar 2004 15:42:47 -0700 Subject: xfsrestore and inode number/generation To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: James A Goodwin Date: Thu, 18 Mar 2004 16:42:40 -0600 X-MIMETrack: Serialize by Router on D03NM131/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 03/18/2004 15:42:46 MIME-Version: 1.0 Content-Disposition: inline Content-type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 2500 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jagoodwi@us.ibm.com Precedence: bulk X-list: linux-xfs Content-Length: 490 Lines: 23 When recovering a filesystem using xfsrestore, is there no way to preserve the inode number & generation for restored files? If not, then users of DMAPI need to be aware that DM handles (which are based at least partly on these values) are likely to change when a system is restored from backup. Regards, -James Goodwin Software Engineer IBM Business Consulting Services jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu Mar 18 15:48:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Mar 2004 15:48:03 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2INm1KO020290 for ; Thu, 18 Mar 2004 15:48:01 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2J1o344026057 for ; Thu, 18 Mar 2004 17:50:04 -0800 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i2INltwJ009563 for ; Fri, 19 Mar 2004 10:47:55 +1100 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i2INlsJc009562 for linux-xfs@oss.sgi.com; Fri, 19 Mar 2004 10:47:54 +1100 Date: Fri, 19 Mar 2004 10:47:54 +1100 From: FSG QA Message-Id: <200403182347.i2INlsJc009562@bruce.melbourne.sgi.com> Subject: TAKE - xfstests X-archive-position: 2501 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 369 Lines: 14 Merge in recent fsx changes from outside - AIO and direct IO support. Date: Thu Mar 18 15:46:57 PST 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:168751a xfstests/ltp/fsx.c - 1.3 xfstests/ltp/Makefile - 1.3 From owner-linux-xfs@oss.sgi.com Thu Mar 18 17:51:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Mar 2004 17:51:20 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2J1p2KO026698 for ; Thu, 18 Mar 2004 17:51:03 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2J2pciQ002281 for ; Thu, 18 Mar 2004 18:51:38 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2J1oqAL12379907; Fri, 19 Mar 2004 12:50:52 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2J1oosf12402515; Fri, 19 Mar 2004 12:50:50 +1100 (EST) Date: Fri, 19 Mar 2004 12:50:50 +1100 (EST) From: Nathan Scott Message-Id: <200403190150.i2J1oosf12402515@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: PARTIAL TAKE 911227 - xfs_repair X-archive-position: 2502 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 348 Lines: 13 Plug a repair problem when checking directories with an initial hole. Date: Thu Mar 18 17:50:13 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: cattelan@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:168756a xfsprogs/repair/phase6.c - 1.18 From owner-linux-xfs@oss.sgi.com Thu Mar 18 17:54:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Mar 2004 17:54:41 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2J1sdKO027152 for ; Thu, 18 Mar 2004 17:54:39 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2J2tFiQ002309 for ; Thu, 18 Mar 2004 18:55:15 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2J1sPAL12313657; Fri, 19 Mar 2004 12:54:25 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2J1sOlx12389045; Fri, 19 Mar 2004 12:54:24 +1100 (EST) Date: Fri, 19 Mar 2004 12:54:24 +1100 (EST) From: Nathan Scott Message-Id: <200403190154.i2J1sOlx12389045@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 911226 - xfs_copy X-archive-position: 2503 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 376 Lines: 14 Fix endian bug in xfs_copy, when dealing with fragmented freespace (multi-level freespace btrees). Date: Thu Mar 18 17:53:26 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: cattelan@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:168757a xfsprogs/copy/xfs_copy.c - 1.7 From owner-linux-xfs@oss.sgi.com Thu Mar 18 17:57:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Mar 2004 17:57:40 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2J1vcKO027607 for ; Thu, 18 Mar 2004 17:57:38 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2J2wDiQ002572 for ; Thu, 18 Mar 2004 18:58:14 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2J1vSAL12375152; Fri, 19 Mar 2004 12:57:28 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2J1vQne12411224; Fri, 19 Mar 2004 12:57:26 +1100 (EST) Date: Fri, 19 Mar 2004 12:57:26 +1100 (EST) From: Nathan Scott Message-Id: <200403190157.i2J1vQne12411224@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 911512 - xfs_repair X-archive-position: 2504 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 382 Lines: 14 Prevent setsize ioctl warnings in repair when running in "dangerous" mode. Date: Thu Mar 18 17:56:50 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:168758a xfsprogs/repair/init.c - 1.11 xfsprogs/repair/xfs_repair.c - 1.16 From owner-linux-xfs@oss.sgi.com Thu Mar 18 18:01:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Mar 2004 18:01:15 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2J21AKO028113 for ; Thu, 18 Mar 2004 18:01:13 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2J31kiQ002837 for ; Thu, 18 Mar 2004 19:01:47 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2J211AL11748789; Fri, 19 Mar 2004 13:01:01 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2J210WB12418153; Fri, 19 Mar 2004 13:01:00 +1100 (EST) Date: Fri, 19 Mar 2004 13:01:00 +1100 (EST) From: Nathan Scott Message-Id: <200403190201.i2J210WB12418153@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 910637 - configure/libuuid X-archive-position: 2505 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 749 Lines: 26 Simpler fix for the libuuid problem from awhile ago, works with all autoconf versions. Sync up the dump and xfstests versions of these same macros too. Bump xfsprogs version for last round of changes Date: Thu Mar 18 17:59:30 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: hch@lst.de The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:168759a xfsprogs/configure.in - 1.31 xfsprogs/doc/CHANGES - 1.138 xfsprogs/debian/changelog - 1.91 xfsprogs/debian/rules - 1.21 xfsprogs/m4/package_uuiddev.m4 - 1.7 xfsprogs/aclocal.m4 - 1.8 xfsdump/m4/package_uuiddev.m4 - 1.5 xfsdump/aclocal.m4 - 1.9 xfstests/m4/package_uuiddev.m4 - 1.2 xfstests/aclocal.m4 - 1.4 From owner-linux-xfs@oss.sgi.com Fri Mar 19 01:25:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Mar 2004 01:25:20 -0800 (PST) Received: from alienAngel.upjs.sk (styx.suse.cz [82.208.2.94]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2J9PFKO019381 for ; Fri, 19 Mar 2004 01:25:15 -0800 Received: by alienAngel.upjs.sk (Postfix, from userid 500) id ADB7117C; Fri, 19 Mar 2004 10:27:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by alienAngel.upjs.sk (Postfix) with ESMTP id A9C0F178 for ; Fri, 19 Mar 2004 10:27:31 +0100 (CET) Date: Fri, 19 Mar 2004 10:27:31 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: linux-xfs@oss.sgi.com Subject: Space calculation Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2506 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 1887 Lines: 50 Hi. I would like to ask how much space needs xfs for empty files? I tested fix for bug #284. Good work, it works for me. But I created file system on loop device with size 512MB and ran bonnie++: # mkfs.xfs /dev/loop0 meta-data=/dev/loop0 isize=256 agcount=8, agsize=16384 blks = sectsz=512 data = bsize=4096 blocks=131072, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 /tmp/bonnie++-1.02c/bonnie++ -d /mnt/mnt2 -u 0:0 -s 0 -n 500 Everything was fine, maximum alocated space was 29%: /dev/loop0 519488 148032 371456 29% /mnt/mnt2 Then I created 500MB FS and I used modified bonnie according bug #284 comment #9. # mkfs.xfs /dev/loop0 meta-data=/dev/loop0 isize=256 agcount=8, agsize=16000 blks = sectsz=512 data = bsize=4096 blocks=128000, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 Bonnie ended with this output: # /tmp/bonnie++-1.02c/bonnie++ -d /mnt/mnt2 -u 0:0 -s 0 -n 500 Using uid:0, gid:0. Create files in sequential order...Can't create file 0511996x7MCG: No space left on device Cleaning up test directory after error. My question is why xfs (in this case) needs almost 4x bigger FS than is size of allocated space? jan -- From owner-linux-xfs@oss.sgi.com Fri Mar 19 05:45:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Mar 2004 05:45:45 -0800 (PST) Received: from relay02.roc.ny.frontiernet.net (relay02.roc.ny.frontiernet.net [66.133.131.35]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2JDjfKO032539 for ; Fri, 19 Mar 2004 05:45:42 -0800 Received: (qmail 25090 invoked from network); 19 Mar 2004 13:45:41 -0000 Received: from unknown (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay02.roc.ny.frontiernet.net (FrontierMTA 2.3.7b) with SMTP for ; 19 Mar 2004 13:45:41 -0000 Message-ID: <405AF94A.30804@xfs.org> Date: Fri, 19 Mar 2004 07:44:42 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jan Derfinak CC: linux-xfs@oss.sgi.com Subject: Re: Space calculation References: In-Reply-To: Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2507 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1694 Lines: 41 Jan Derfinak wrote: > Hi. > > I would like to ask how much space needs xfs for empty files? > I tested fix for bug #284. Good work, it works for me. > But I created file system on loop device with size 512MB and ran bonnie++: > > # mkfs.xfs /dev/loop0 > meta-data=/dev/loop0 isize=256 agcount=8, agsize=16384 blks > = sectsz=512 > data = bsize=4096 blocks=131072, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=1200, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > /tmp/bonnie++-1.02c/bonnie++ -d /mnt/mnt2 -u 0:0 -s 0 -n 500 > > Everything was fine, maximum alocated space was 29%: > > /dev/loop0 519488 148032 371456 29% /mnt/mnt2 > > Then I created 500MB FS and I used modified bonnie according bug #284 > comment #9. > > # mkfs.xfs /dev/loop0 > meta-data=/dev/loop0 isize=256 agcount=8, agsize=16000 blks > = sectsz=512 > data = bsize=4096 blocks=128000, imaxpct=25 ^^^^^^^^ This is why you ran out of space, imaxpct is saying that 25% of the filesystem can be consumed by inodes. The invocation of bonnie++ creates half a million files. You can change this with mkfs options or with xfs_growfs. Your second filesystem was smaller, 25% of 128000 blocks is 32000 which is 512000 inodes. Looks like the calculation was slightly off, but basically correct. Steve From owner-linux-xfs@oss.sgi.com Fri Mar 19 07:52:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Mar 2004 07:52:32 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2JFqIKO003820 for ; Fri, 19 Mar 2004 07:52:18 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2JGqwiQ019132 for ; Fri, 19 Mar 2004 08:52:58 -0800 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2JFqBKe35579006; Fri, 19 Mar 2004 09:52:11 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i2JFqBGa637216; Fri, 19 Mar 2004 09:52:11 -0600 (CST) Received: from clink (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id i2JFqA9i24694518; Fri, 19 Mar 2004 09:52:11 -0600 (CST) Message-Id: <200403191552.i2JFqA9i24694518@clink.americas.sgi.com> To: James A Goodwin cc: linux-xfs@oss.sgi.com Subject: Re: xfsrestore and inode number/generation Date: Fri, 19 Mar 2004 09:52:10 -0600 From: Dean Roehrich X-archive-position: 2508 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 803 Lines: 21 >From: James A Goodwin >When recovering a filesystem using xfsrestore, is there no way to preserve >the inode number & generation for restored files? The inode number encodes the allocation group (AG), block within the AG, and offset to the inode--there is no interface to XFS that allows you to specify all that info when you create a new file. >If not, then users of DMAPI need to be aware that DM handles (which are >based at least partly on these values) are likely to change when a system >is restored from backup. The handles encode the inode number, the inode generation number, and the filesystem id. If you mkfs your filesystem before doing the xfsrestore then there will not only be a change of inode number and generation number but also of filesystem id. Dean From owner-linux-xfs@oss.sgi.com Fri Mar 19 11:48:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Mar 2004 11:48:13 -0800 (PST) Received: from alienAngel.upjs.sk (gprs185-222.eurotel.cz [160.218.185.222]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2JJm0KO016516 for ; Fri, 19 Mar 2004 11:48:06 -0800 Received: by alienAngel.upjs.sk (Postfix, from userid 500) id DDA2317A; Fri, 19 Mar 2004 20:50:10 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by alienAngel.upjs.sk (Postfix) with ESMTP id AD1B2178; Fri, 19 Mar 2004 20:50:10 +0100 (CET) Date: Fri, 19 Mar 2004 20:50:10 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: Space calculation In-Reply-To: <405AF94A.30804@xfs.org> Message-ID: References: <405AF94A.30804@xfs.org> MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2509 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 573 Lines: 19 On Fri, 19 Mar 2004, Steve Lord wrote: Hi. > This is why you ran out of space, imaxpct is saying that 25% of the > filesystem can be consumed by inodes. The invocation of bonnie++ > creates half a million files. You can change this with mkfs options > or with xfs_growfs. Your second filesystem was smaller, 25% of 128000 > blocks is 32000 which is 512000 inodes. Looks like the calculation > was slightly off, but basically correct. Thanks for answer, you are right. Maximum inode usage was 512004 inodes. After enlarging imaxpct bonnie completed test. jan -- From owner-linux-xfs@oss.sgi.com Fri Mar 19 12:52:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Mar 2004 12:52:42 -0800 (PST) Received: from lancia.kaluga.ru (lancia.kaluga.ru [62.148.128.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2JKqaKO021352 for ; Fri, 19 Mar 2004 12:52:38 -0800 Received: from juliya (esta.kaluga.ru [62.148.142.144]) by lancia.kaluga.ru (8.12.10/8.12.10) with SMTP id i2JKqPlw099275 for ; Fri, 19 Mar 2004 23:52:26 +0300 (MSK) X-AntiVirus: Checked by Dr.Web (http://www.drweb.net) From: "Romkat" To: Subject: XFS and RH 7.3 (Valhalla) Date: Fri, 19 Mar 2004 23:52:24 +0300 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 2510 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: home@esta.kaluga.ru Precedence: bulk X-list: linux-xfs Content-Length: 198 Lines: 4 Hello, Prompt please what kernel to use for XFS, if beside me installing operating system "Red Hat Linux release 7.3 (Valhalla) Kernel 2.4.18-10 on an i686" ? if possible, give please direct link. From owner-linux-xfs@oss.sgi.com Fri Mar 19 14:15:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Mar 2004 14:15:15 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2JMFAKO024226 for ; Fri, 19 Mar 2004 14:15:10 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2JN8FiQ008836 for ; Fri, 19 Mar 2004 15:08:15 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2JM7QKe35647595; Fri, 19 Mar 2004 16:07:26 -0600 (CST) Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i2JM7QXa1942967; Fri, 19 Mar 2004 16:07:26 -0600 (CST) Subject: Re: XFS and RH 7.3 (Valhalla) From: Russell Cattelan To: Romkat Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-type: text/plain Message-Id: <1079734046.3373.38.camel@naboo.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5-4mdk Date: Fri, 19 Mar 2004 16:07:26 -0600 Content-Transfer-Encoding: 8bit X-archive-position: 2511 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 733 Lines: 21 On Fri, 2004-03-19 at 14:52, Romkat wrote: > Hello, Prompt please what kernel to use for XFS, if beside me installing > operating system "Red Hat Linux release 7.3 (Valhalla) Kernel 2.4.18-10 on > an i686" ? if possible, give please direct link. > If you grab this src rpm and rebuild on you're system ftp://oss.sgi.com/projects/xfs/Release-1.3.1/kernel_rpms/RedHatLinux9/SRPMS/kernel-2.4.20-20.9.XFS1.3.1.src.rpm -- Attached file included as plaintext by Ecartis -- -- File: signature.asc -- Desc: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBAW28dNRmM+OaGhBgRAkYcAJ98Ee58Fsrqg0XKReCuHpShduZ5kwCeP1IH KBfFa7b3pIJ/aSguWpmjwgg= =QXm6 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Mar 19 14:52:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Mar 2004 14:52:38 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2JMqZKO027940 for ; Fri, 19 Mar 2004 14:52:35 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2K0slIC018991 for ; Fri, 19 Mar 2004 16:54:48 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2JMqTKe35621598 for ; Fri, 19 Mar 2004 16:52:30 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1B4Sqr-0001ts-00 for ; Fri, 19 Mar 2004 16:52:29 -0600 Date: Fri, 19 Mar 2004 16:52:28 -0600 From: Nathan Straz To: linux-xfs@oss.sgi.com Subject: TAKE 910887 - fix max file size case Message-ID: <20040319225228.GI22432@sgi.com> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2512 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 709 Lines: 22 Fix the case where we write to a file with max file size. We weren't able to convert the last block if it was dealloc. Date: Fri Mar 19 14:46:00 PST 2004 Workarea: maine.americas.sgi.com:/extra/wa/xfs-linux Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:168809a linux-2.6/xfs_aops.c - 1.67 linux-2.4/xfs_aops.c - 1.77 - Use unsigned long long for end_offset so we don't overflow it. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Fri Mar 19 21:42:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Mar 2004 21:42:28 -0800 (PST) Received: from moria.linuxis.net (moria.linuxis.net [209.237.231.67]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2K5gMKO012265 for ; Fri, 19 Mar 2004 21:42:25 -0800 Received: (qmail 25838 invoked from network); 20 Mar 2004 05:29:07 -0000 Received: from unknown (HELO shoshana.dnsalias.org) (67.173.135.227) by 209.237.231.80 with SMTP; 20 Mar 2004 05:29:07 -0000 Received: (qmail 2005 invoked by uid 501); 20 Mar 2004 05:42:41 -0000 Date: Fri, 19 Mar 2004 23:42:19 -0600 From: John Palkovic To: linux-xfs@oss.sgi.com Subject: Re: 2.6.4 can't mount root xfs Message-ID: <20040320054219.GA1936@palkovic.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20040316193914.GA1564@palkovic.org> <20040316194423.A4914@infradead.org> <20040318191523.GA1592@palkovic.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040318191523.GA1592@palkovic.org> User-Agent: Mutt/1.5.5.1+cvs20040105i Content-Transfer-Encoding: 8bit X-archive-position: 2513 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scientist@palkovic.org Precedence: bulk X-list: linux-xfs Content-Length: 736 Lines: 21 I can now report that my system boots with an XFS root partition. I'm posting this here in the hope that it might save someone some time and frustration in the future. The fix was to add the following options to my .config, from File Systems --> Partition Types CONFIG_PARTITION_ADVANCED=y CONFIG_MSDOS_PARTITION=y The strange thing is that this only seems to be necessary when root is formatted as an XFS partition. If I format it, e.g., as ext3, then I can boot with a 2.6.4 kernel that does not have these two options set. With 2.6.3, they don't need to be set. -John -- "The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell From owner-linux-xfs@oss.sgi.com Fri Mar 19 22:22:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Mar 2004 22:22:36 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:FbI8BrixnphdjYFIU4xndiy3fkxkueQy@12-222-156-122.client.insightBB.com [12.222.156.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2K6MWKO013653 for ; Fri, 19 Mar 2004 22:22:34 -0800 Received: from localhost (burgers.bubbanfriends.org [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 4D5441421001; Sat, 20 Mar 2004 01:23:25 -0500 (EST) Received: from burgers.bubbanfriends.org ([127.0.0.1]) by localhost (burgers.bubbanfriends.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20257-03; Sat, 20 Mar 2004 01:23:23 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 5BF0E1421000; Sat, 20 Mar 2004 01:23:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 4D2FA30002A2; Sat, 20 Mar 2004 01:23:23 -0500 (EST) Date: Sat, 20 Mar 2004 01:23:23 -0500 (EST) From: Mike Burger To: John Palkovic Cc: linux-xfs@oss.sgi.com Subject: Re: 2.6.4 can't mount root xfs In-Reply-To: <20040320054219.GA1936@palkovic.org> Message-ID: References: <20040316193914.GA1564@palkovic.org> <20040316194423.A4914@infradead.org> <20040318191523.GA1592@palkovic.org> <20040320054219.GA1936@palkovic.org> MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new at bubbanfriends.org Content-Transfer-Encoding: 8bit X-archive-position: 2514 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 1095 Lines: 34 On Fri, 19 Mar 2004, John Palkovic wrote: > I can now report that my system boots with an XFS root partition. I'm > posting this here in the hope that it might save someone some time and > frustration in the future. The fix was to add the following options to my > .config, from File Systems --> Partition Types > > CONFIG_PARTITION_ADVANCED=y > CONFIG_MSDOS_PARTITION=y > > The strange thing is that this only seems to be necessary when root is > formatted as an XFS partition. If I format it, e.g., as ext3, then I can > boot with a 2.6.4 kernel that does not have these two options set. With > 2.6.3, they don't need to be set. Silly question, but do you have a separate partition for /boot, or is it sitting off of / in the root partition? -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Fri Mar 19 22:46:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Mar 2004 22:46:43 -0800 (PST) Received: from moria.linuxis.net (moria.linuxis.net [209.237.231.67]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2K6kYKO014645 for ; Fri, 19 Mar 2004 22:46:34 -0800 Received: (qmail 30752 invoked from network); 20 Mar 2004 06:33:16 -0000 Received: from unknown (HELO shoshana.dnsalias.org) (67.173.135.227) by 209.237.231.80 with SMTP; 20 Mar 2004 06:33:16 -0000 Received: (qmail 2538 invoked by uid 501); 20 Mar 2004 06:46:51 -0000 Date: Sat, 20 Mar 2004 00:46:29 -0600 From: John Palkovic To: linux-xfs@oss.sgi.com Subject: Re: 2.6.4 can't mount root xfs Message-ID: <20040320064629.GB1936@palkovic.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20040316193914.GA1564@palkovic.org> <20040316194423.A4914@infradead.org> <20040318191523.GA1592@palkovic.org> <20040320054219.GA1936@palkovic.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i Content-Transfer-Encoding: 8bit X-archive-position: 2515 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scientist@palkovic.org Precedence: bulk X-list: linux-xfs Content-Length: 604 Lines: 19 On Sat, Mar 20, 2004 at 01:23:01AM -0500, Mike Burger wrote: > Silly question, but do you have a separate partition for /boot, or is it > sitting off of / in the root partition? Separate: Filesystem Size Used Avail Use% Mounted on /dev/sda5 498M 270M 229M 55% / /dev/sda1 23M 6.9M 15M 32% /boot /dev/sda6 1.9G 1.5G 465M 77% /usr /dev/sda7 5.8G 2.5G 3.3G 44% /home -- "The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell From owner-linux-xfs@oss.sgi.com Sat Mar 20 06:26:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 20 Mar 2004 06:26:20 -0800 (PST) Received: from hermes.uci.kun.nl (hermes.uci.kun.nl [131.174.93.58]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2KEQ9KO003907 for ; Sat, 20 Mar 2004 06:26:10 -0800 Received: from gateway.flat145.net (vhe-765107.sshn.net [195.169.212.32]) by hermes.uci.kun.nl (PMDF V6.2-X17 #30689) with ESMTP id <0HUV00E53GC9K0@hermes.uci.kun.nl> for linux-xfs@oss.sgi.com; Sat, 20 Mar 2004 12:09:45 +0100 (MET) Received: from seiryuu.flat145.net ([192.168.15.2] helo=seiryuu ident=Debian-exim) by gateway.flat145.net with esmtp (Exim 3.35 #1 (Debian)) id 1B4eM7-0000XR-00 for ; Sat, 20 Mar 2004 12:09:31 +0100 Received: from shadur by seiryuu with local (Exim 4.30) id 1B4eM7-0006Ig-7G for linux-xfs@oss.sgi.com; Sat, 20 Mar 2004 12:09:31 +0100 Date: Sat, 20 Mar 2004 12:09:31 +0100 From: Rens Houben Subject: Kernel oops in XFS, kernel 2.6.4 To: linux-xfs@oss.sgi.com Message-id: <20040320110931.GA19008@seiryuu.systemec.nl> MIME-version: 1.0 Content-type: text/plain Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i Content-Transfer-Encoding: 8bit X-archive-position: 2516 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: shadur@seiryuu.systemec.nl Precedence: bulk X-list: linux-xfs Content-Length: 31804 Lines: 1407 See the attached file for a syslog of the oops; it was followed shortly after by the system locking hard. Specs: Athlon XP 2600 1024 Mb Ram nvidia GeForce 4 Ti4200 (hence the taint; I'm using the nvidia driver) Debian sid; latest updates as of about two hours before the oops occurred. kernel compiled with gcc version 3.3.3 (Debian-20040314) kernel config file attached below. What I Was Doing: Not much out of the ordinary. Running XFree and gnome 2.4, playing mp3s on xmms, ssh in a term to my IRC session elsewhere, and patching the kernel source tree from 2.6.4-mm2 (which didn't manage to compile) to 2.6.4 proper. Halfway down it halted and dmesg showed that error. Hope this is of use to you all. Considering that this is only the second or so actual XFS oops I've run into in the several years I've been using it as my FS of choice (with some *highly* flaky hardware at some points), I'd like to congratulate you all on the quality of your work. Shad. -- Attached file included as plaintext by Ecartis -- Mar 20 11:14:56 seiryuu kernel: Unable to handle kernel paging request at virtual address 6b6b6d57 Mar 20 11:14:56 seiryuu kernel: printing eip: Mar 20 11:14:56 seiryuu kernel: c0218049 Mar 20 11:14:56 seiryuu kernel: *pde = 00000000 Mar 20 11:14:56 seiryuu kernel: Oops: 0000 [#1] Mar 20 11:14:56 seiryuu kernel: PREEMPT Mar 20 11:14:56 seiryuu kernel: CPU: 0 Mar 20 11:14:56 seiryuu kernel: EIP: 0060:[] Tainted: PF Mar 20 11:14:56 seiryuu kernel: EFLAGS: 00210202 Mar 20 11:14:56 seiryuu kernel: EIP is at xfs_trans_unlocked_item+0x19/0x60 Mar 20 11:14:56 seiryuu kernel: eax: 6b6b6b6b ebx: 6b6b6b6b ecx: e33a5270 edx: 00000001 Mar 20 11:14:56 seiryuu kernel: esi: d09bf7a4 edi: 00000000 ebp: f7c1b600 esp: de821d3c Mar 20 11:14:56 seiryuu kernel: ds: 007b es: 007b ss: 0068 Mar 20 11:14:56 seiryuu kernel: Process rm (pid: 9121, threadinfo=de820000 task=eaa671e0) Mar 20 11:14:56 seiryuu kernel: Stack: ffffff00 c01fd642 00000060 d09bf7a4 e33a5270 c020375b 6b6b6b6b d09bf7a4 Mar 20 11:14:56 seiryuu kernel: 00000000 00000010 00004000 c02035b0 de820000 d09bf7a4 f7c1b600 de821db0 Mar 20 11:14:56 seiryuu kernel: c0217ff3 d09bf7a4 d09bf1b4 de821db0 de821dac 00000000 00006e94 00000041 Mar 20 11:14:56 seiryuu kernel: Call Trace: Mar 20 11:14:56 seiryuu kernel: [] xfs_iunlock+0x62/0xa0 Mar 20 11:14:56 seiryuu kernel: [] xfs_inode_item_pushbuf+0x3b/0x1b0 Mar 20 11:14:56 seiryuu kernel: [] xfs_inode_item_trylock+0x50/0xb0 Mar 20 11:14:56 seiryuu kernel: [] xfs_trans_push_ail+0x213/0x250 Mar 20 11:14:56 seiryuu kernel: [] xlog_grant_push_ail+0x13e/0x180 Mar 20 11:14:56 seiryuu kernel: [] xfs_log_reserve+0x51/0xd0 Mar 20 11:14:56 seiryuu kernel: [] xfs_trans_reserve+0x83/0x1c0 Mar 20 11:14:56 seiryuu kernel: [] xfs_itruncate_finish+0x294/0x440 Mar 20 11:14:56 seiryuu kernel: [] xfs_inactive+0x4f9/0x550 Mar 20 11:14:56 seiryuu kernel: [] vn_rele+0xc1/0xd0 Mar 20 11:14:56 seiryuu kernel: [] linvfs_clear_inode+0x18/0x30 Mar 20 11:14:56 seiryuu kernel: [] clear_inode+0xb6/0xd0 Mar 20 11:14:56 seiryuu kernel: [] generic_delete_inode+0x138/0x170 Mar 20 11:14:56 seiryuu kernel: [] sys_unlink+0x102/0x140 Mar 20 11:14:56 seiryuu kernel: [] iput+0x62/0x80 Mar 20 11:14:56 seiryuu kernel: [] sys_unlink+0x10e/0x140 Mar 20 11:14:56 seiryuu kernel: [] sysenter_past_esp+0x52/0x71 Mar 20 11:14:56 seiryuu kernel: Mar 20 11:14:56 seiryuu kernel: Code: f6 83 ec 01 00 00 10 74 0c 8b 5c 24 0c 8b 74 24 10 83 c4 14 -- Attached file included as plaintext by Ecartis -- # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_STANDALONE=y CONFIG_BROKEN_ON_SMP=y # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_HOTPLUG=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MELAN is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # CONFIG_EDD is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y CONFIG_HIGHPTE=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y # CONFIG_REGPARM is not set # # Power management options (ACPI, APM) # # CONFIG_PM is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=m # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_X86_PM_TIMER is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_USE_VECTOR=y CONFIG_PCI_LEGACY_PROC=y CONFIG_PCI_NAMES=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set # # PCI Hotplug Support # CONFIG_HOTPLUG_PCI=m CONFIG_HOTPLUG_PCI_FAKE=m # CONFIG_HOTPLUG_PCI_COMPAQ is not set # CONFIG_HOTPLUG_PCI_IBM is not set # CONFIG_HOTPLUG_PCI_ACPI is not set # CONFIG_HOTPLUG_PCI_CPCI is not set # CONFIG_HOTPLUG_PCI_PCIE is not set # CONFIG_HOTPLUG_PCI_SHPC is not set # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_MISC=m # # Device Drivers # # # Generic Driver Options # CONFIG_FW_LOADER=m # CONFIG_DEBUG_DRIVER is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m # CONFIG_PARPORT_SERIAL is not set CONFIG_PARPORT_PC_FIFO=y # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_OTHER is not set # CONFIG_PARPORT_1284 is not set # # Plug and Play support # # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y # CONFIG_LBD is not set # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_IDEDISK_STROKE is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_IDE_TASK_IOCTL is not set CONFIG_IDE_TASKFILE_IO=y # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=y CONFIG_BLK_DEV_CMD640=y # CONFIG_BLK_DEV_CMD640_ENHANCED is not set CONFIG_BLK_DEV_IDEPCI=y # CONFIG_IDEPCI_SHARE_IRQ is not set # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=y # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set CONFIG_BLK_DEV_AMD74XX=y # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_SC1200 is not set # CONFIG_BLK_DEV_PIIX is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=y CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_DMA_NONPCI is not set # CONFIG_BLK_DEV_HD is not set # # SCSI device support # CONFIG_SCSI=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set CONFIG_SCSI_REPORT_LUNS=y # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_MEGARAID is not set CONFIG_SCSI_SATA=y # CONFIG_SCSI_SATA_SVW is not set # CONFIG_SCSI_ATA_PIIX is not set # CONFIG_SCSI_SATA_PROMISE is not set CONFIG_SCSI_SATA_VIA=y # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set CONFIG_SCSI_QLA2XXX=y # CONFIG_SCSI_QLA21XX is not set # CONFIG_SCSI_QLA22XX is not set # CONFIG_SCSI_QLA2300 is not set # CONFIG_SCSI_QLA2322 is not set # CONFIG_SCSI_QLA6312 is not set # CONFIG_SCSI_QLA6322 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # CONFIG_IEEE1394=m # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set CONFIG_IEEE1394_OUI_DB=y # CONFIG_IEEE1394_EXTRA_CONFIG_ROMS is not set # # Device Drivers # # # Texas Instruments PCILynx requires I2C # CONFIG_IEEE1394_OHCI1394=m # # Protocol Drivers # # CONFIG_IEEE1394_VIDEO1394 is not set # CONFIG_IEEE1394_SBP2 is not set # CONFIG_IEEE1394_ETH1394 is not set # CONFIG_IEEE1394_DV1394 is not set # CONFIG_IEEE1394_RAWIO is not set # CONFIG_IEEE1394_CMP is not set # # I2O device support # # CONFIG_I2O is not set # # Macintosh device drivers # # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK_DEV=m CONFIG_UNIX=y CONFIG_NET_KEY=y CONFIG_INET=y # CONFIG_IP_MULTICAST is not set CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_ROUTE_NAT=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_TOS=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=y CONFIG_INET_ESP=y CONFIG_INET_IPCOMP=y # # IP: Virtual Server Configuration # CONFIG_IP_VS=m # CONFIG_IP_VS_DEBUG is not set CONFIG_IP_VS_TAB_BITS=12 # # IPVS transport protocol load balancing support # CONFIG_IP_VS_PROTO_TCP=y CONFIG_IP_VS_PROTO_UDP=y CONFIG_IP_VS_PROTO_ESP=y CONFIG_IP_VS_PROTO_AH=y # # IPVS scheduler # CONFIG_IP_VS_RR=m CONFIG_IP_VS_WRR=m CONFIG_IP_VS_LC=m CONFIG_IP_VS_WLC=m CONFIG_IP_VS_LBLC=m CONFIG_IP_VS_LBLCR=m CONFIG_IP_VS_DH=m CONFIG_IP_VS_SH=m CONFIG_IP_VS_SED=m CONFIG_IP_VS_NQ=m # # IPVS application helper # # CONFIG_IP_VS_FTP is not set CONFIG_IPV6=y CONFIG_IPV6_PRIVACY=y CONFIG_INET6_AH=y CONFIG_INET6_ESP=y CONFIG_INET6_IPCOMP=y CONFIG_IPV6_TUNNEL=y # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_FTP=y CONFIG_IP_NF_IRC=y CONFIG_IP_NF_TFTP=m # CONFIG_IP_NF_AMANDA is not set # CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_LIMIT=y CONFIG_IP_NF_MATCH_IPRANGE=y CONFIG_IP_NF_MATCH_MAC=y # CONFIG_IP_NF_MATCH_PKTTYPE is not set CONFIG_IP_NF_MATCH_MARK=y CONFIG_IP_NF_MATCH_MULTIPORT=y CONFIG_IP_NF_MATCH_TOS=y CONFIG_IP_NF_MATCH_RECENT=m # CONFIG_IP_NF_MATCH_ECN is not set # CONFIG_IP_NF_MATCH_DSCP is not set CONFIG_IP_NF_MATCH_AH_ESP=y CONFIG_IP_NF_MATCH_LENGTH=y CONFIG_IP_NF_MATCH_TTL=y CONFIG_IP_NF_MATCH_TCPMSS=y # CONFIG_IP_NF_MATCH_HELPER is not set CONFIG_IP_NF_MATCH_STATE=y # CONFIG_IP_NF_MATCH_CONNTRACK is not set CONFIG_IP_NF_MATCH_OWNER=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_IP_NF_TARGET_REDIRECT=y CONFIG_IP_NF_TARGET_NETMAP=y CONFIG_IP_NF_TARGET_SAME=m # CONFIG_IP_NF_NAT_LOCAL is not set CONFIG_IP_NF_NAT_SNMP_BASIC=y CONFIG_IP_NF_NAT_IRC=y CONFIG_IP_NF_NAT_FTP=y CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_MANGLE=y CONFIG_IP_NF_TARGET_TOS=y # CONFIG_IP_NF_TARGET_ECN is not set # CONFIG_IP_NF_TARGET_DSCP is not set CONFIG_IP_NF_TARGET_MARK=y CONFIG_IP_NF_TARGET_CLASSIFY=m CONFIG_IP_NF_TARGET_LOG=y CONFIG_IP_NF_TARGET_ULOG=y # CONFIG_IP_NF_TARGET_TCPMSS is not set # CONFIG_IP_NF_ARPTABLES is not set # # IPv6: Netfilter Configuration # # CONFIG_IP6_NF_QUEUE is not set CONFIG_IP6_NF_IPTABLES=y CONFIG_IP6_NF_MATCH_LIMIT=y CONFIG_IP6_NF_MATCH_MAC=y # CONFIG_IP6_NF_MATCH_RT is not set # CONFIG_IP6_NF_MATCH_OPTS is not set # CONFIG_IP6_NF_MATCH_FRAG is not set # CONFIG_IP6_NF_MATCH_HL is not set CONFIG_IP6_NF_MATCH_MULTIPORT=y CONFIG_IP6_NF_MATCH_OWNER=y CONFIG_IP6_NF_MATCH_MARK=y # CONFIG_IP6_NF_MATCH_IPV6HEADER is not set # CONFIG_IP6_NF_MATCH_AHESP is not set # CONFIG_IP6_NF_MATCH_LENGTH is not set # CONFIG_IP6_NF_MATCH_EUI64 is not set CONFIG_IP6_NF_FILTER=y CONFIG_IP6_NF_TARGET_LOG=y CONFIG_IP6_NF_MANGLE=y CONFIG_IP6_NF_TARGET_MARK=y CONFIG_XFRM=y CONFIG_XFRM_USER=y # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IPV6_SCTP__=y CONFIG_IP_SCTP=m # CONFIG_SCTP_DBG_MSG is not set # CONFIG_SCTP_DBG_OBJCNT is not set # CONFIG_SCTP_HMAC_NONE is not set # CONFIG_SCTP_HMAC_SHA1 is not set CONFIG_SCTP_HMAC_MD5=y # CONFIG_ATM is not set # CONFIG_VLAN_8021Q is not set CONFIG_LLC=m # CONFIG_LLC2 is not set CONFIG_IPX=m CONFIG_IPX_INTERN=y # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set CONFIG_TUN=m # CONFIG_ETHERTAP is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=y # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set CONFIG_NET_VENDOR_3COM=y CONFIG_VORTEX=m # CONFIG_TYPHOON is not set # # Tulip family network device support # # CONFIG_NET_TULIP is not set # CONFIG_HP100 is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_B44 is not set # CONFIG_FORCEDETH is not set # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set # CONFIG_E100 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set CONFIG_NE2K_PCI=y # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SK98LIN is not set # CONFIG_TIGON3 is not set # # Ethernet (10000 Mbit) # # CONFIG_IXGB is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set CONFIG_PPP=m CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPPOE=m # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # Bluetooth support # # CONFIG_BT is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=m # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # CONFIG_GAMEPORT=m CONFIG_SOUND_GAMEPORT=m # CONFIG_GAMEPORT_NS558 is not set # CONFIG_GAMEPORT_L4 is not set CONFIG_GAMEPORT_EMU10K1=m # CONFIG_GAMEPORT_VORTEX is not set # CONFIG_GAMEPORT_FM801 is not set # CONFIG_GAMEPORT_CS461x is not set CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=m # CONFIG_MOUSE_SERIAL is not set CONFIG_INPUT_JOYSTICK=y CONFIG_JOYSTICK_ANALOG=m # CONFIG_JOYSTICK_A3D is not set CONFIG_JOYSTICK_ADI=m # CONFIG_JOYSTICK_COBRA is not set # CONFIG_JOYSTICK_GF2K is not set # CONFIG_JOYSTICK_GRIP is not set # CONFIG_JOYSTICK_GRIP_MP is not set # CONFIG_JOYSTICK_GUILLEMOT is not set # CONFIG_JOYSTICK_INTERACT is not set # CONFIG_JOYSTICK_SIDEWINDER is not set # CONFIG_JOYSTICK_TMDC is not set # CONFIG_JOYSTICK_IFORCE is not set CONFIG_JOYSTICK_WARRIOR=y # CONFIG_JOYSTICK_MAGELLAN is not set # CONFIG_JOYSTICK_SPACEORB is not set # CONFIG_JOYSTICK_SPACEBALL is not set # CONFIG_JOYSTICK_STINGER is not set # CONFIG_JOYSTICK_TWIDDLER is not set # CONFIG_JOYSTICK_DB9 is not set # CONFIG_JOYSTICK_GAMECON is not set # CONFIG_JOYSTICK_TURBOGRAFX is not set # CONFIG_INPUT_JOYDUMP is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=y # CONFIG_INPUT_UINPUT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y # CONFIG_SERIAL_8250_ACPI is not set CONFIG_SERIAL_8250_NR_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set # CONFIG_PPDEV is not set # CONFIG_TIPAR is not set # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_QIC02_TAPE is not set # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set CONFIG_HW_RANDOM=m CONFIG_NVRAM=y CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=m # CONFIG_AGP_ALI is not set CONFIG_AGP_ATI=m CONFIG_AGP_AMD=m # CONFIG_AGP_AMD64 is not set CONFIG_AGP_INTEL=m CONFIG_AGP_NVIDIA=m # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set CONFIG_AGP_VIA=m # CONFIG_AGP_EFFICEON is not set CONFIG_DRM=y # CONFIG_DRM_TDFX is not set # CONFIG_DRM_GAMMA is not set # CONFIG_DRM_R128 is not set # CONFIG_DRM_RADEON is not set # CONFIG_DRM_I810 is not set # CONFIG_DRM_I830 is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_MWAVE is not set CONFIG_RAW_DRIVER=m CONFIG_MAX_RAW_DEVS=256 CONFIG_HANGCHECK_TIMER=m # # I2C support # # CONFIG_I2C is not set # # Misc devices # # CONFIG_IBM_ASM is not set # # Multimedia devices # CONFIG_VIDEO_DEV=m # # Video For Linux # # # Video Adapters # # CONFIG_VIDEO_BWQCAM is not set # CONFIG_VIDEO_CQCAM is not set # CONFIG_VIDEO_CPIA is not set # CONFIG_VIDEO_STRADIS is not set # CONFIG_VIDEO_MXB is not set # CONFIG_VIDEO_DPC is not set # CONFIG_VIDEO_HEXIUM_ORION is not set # CONFIG_VIDEO_HEXIUM_GEMINI is not set # # Radio Adapters # # CONFIG_RADIO_GEMTEK_PCI is not set # CONFIG_RADIO_MAXIRADIO is not set # CONFIG_RADIO_MAESTRO is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set # # Graphics support # # CONFIG_FB is not set CONFIG_VIDEO_SELECT=y # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_MDA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y # # Sound # CONFIG_SOUND=y # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_SEQUENCER=m # CONFIG_SND_SEQ_DUMMY is not set CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=m # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # # CONFIG_SND_DUMMY is not set # CONFIG_SND_VIRMIDI is not set # CONFIG_SND_MTPAV is not set # CONFIG_SND_SERIAL_U16550 is not set CONFIG_SND_MPU401=m # # PCI devices # # CONFIG_SND_ALI5451 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS4281 is not set CONFIG_SND_EMU10K1=m # CONFIG_SND_KORG1212 is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_YMFPCI is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_SONICVIBES is not set CONFIG_SND_VIA82XX=m # CONFIG_SND_VX222 is not set # # ALSA USB devices # # CONFIG_SND_USB_AUDIO is not set # # Open Sound System # # CONFIG_SOUND_PRIME is not set # # USB support # CONFIG_USB=y # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=y # CONFIG_USB_OHCI_HCD is not set CONFIG_USB_UHCI_HCD=y # # USB Device Class drivers # # CONFIG_USB_AUDIO is not set # CONFIG_USB_BLUETOOTH_TTY is not set # CONFIG_USB_MIDI is not set # CONFIG_USB_ACM is not set CONFIG_USB_PRINTER=m CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_HP8200e is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # # USB Human Interface Devices (HID) # CONFIG_USB_HID=y CONFIG_USB_HIDINPUT=y # CONFIG_HID_FF is not set CONFIG_USB_HIDDEV=y # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_XPAD is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HPUSBSCSI is not set # # USB Multimedia devices # # CONFIG_USB_DABUSB is not set # CONFIG_USB_VICAM is not set # CONFIG_USB_DSBR is not set # CONFIG_USB_IBMCAM is not set # CONFIG_USB_KONICAWC is not set # CONFIG_USB_OV511 is not set # CONFIG_USB_PWC is not set # CONFIG_USB_SE401 is not set # CONFIG_USB_STV680 is not set # # USB Network adaptors # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # # USB port drivers # # CONFIG_USB_USS720 is not set # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_TIGL is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_BRLVGER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_TEST is not set # # USB Gadget Support # # CONFIG_USB_GADGET is not set # # File systems # CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y # CONFIG_EXT2_FS_SECURITY is not set CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y # CONFIG_EXT3_FS_SECURITY is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set CONFIG_FS_POSIX_ACL=y CONFIG_XFS_FS=y CONFIG_XFS_RT=y CONFIG_XFS_QUOTA=y # CONFIG_XFS_SECURITY is not set CONFIG_XFS_POSIX_ACL=y CONFIG_MINIX_FS=m # CONFIG_ROMFS_FS is not set CONFIG_QUOTA=y CONFIG_QFMT_V1=m CONFIG_QFMT_V2=m CONFIG_QUOTACTL=y # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=m CONFIG_UDF_FS=m # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set # CONFIG_NTFS_RW is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y # CONFIG_DEVFS_FS is not set CONFIG_DEVPTS_FS_XATTR=y CONFIG_DEVPTS_FS_SECURITY=y CONFIG_TMPFS=y # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set CONFIG_AFFS_FS=m # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # CONFIG_NFS_FS=m # CONFIG_NFS_V3 is not set # CONFIG_NFS_V4 is not set # CONFIG_NFS_DIRECTIO is not set # CONFIG_NFSD is not set CONFIG_LOCKD=m # CONFIG_EXPORTFS is not set CONFIG_SUNRPC=m # CONFIG_SUNRPC_GSS is not set CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set CONFIG_CIFS=m # CONFIG_NCP_FS is not set CONFIG_CODA_FS=m # CONFIG_CODA_FS_OLD_API is not set # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-15" CONFIG_NLS_CODEPAGE_437=m # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set CONFIG_NLS_CODEPAGE_850=m # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set CONFIG_NLS_CODEPAGE_932=m # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ISO8859_1=m # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=m # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=m # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y CONFIG_EARLY_PRINTK=y CONFIG_DEBUG_STACKOVERFLOW=y # CONFIG_DEBUG_STACK_USAGE is not set CONFIG_DEBUG_SLAB=y # CONFIG_DEBUG_IOVIRT is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_DEBUG_HIGHMEM is not set # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_FRAME_POINTER is not set CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # CONFIG_SECURITY=y # CONFIG_SECURITY_NETWORK is not set CONFIG_SECURITY_CAPABILITIES=y # CONFIG_SECURITY_ROOTPLUG is not set # CONFIG_SECURITY_SELINUX is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_SHA1=y # CONFIG_CRYPTO_SHA256 is not set CONFIG_CRYPTO_SHA512=y CONFIG_CRYPTO_DES=y # CONFIG_CRYPTO_BLOWFISH is not set CONFIG_CRYPTO_TWOFISH=y CONFIG_CRYPTO_SERPENT=y CONFIG_CRYPTO_AES=y # CONFIG_CRYPTO_CAST5 is not set CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_DEFLATE=y # CONFIG_CRYPTO_TEST is not set # # Library routines # CONFIG_CRC32=y CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_PC=y From owner-linux-xfs@oss.sgi.com Sat Mar 20 17:33:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 20 Mar 2004 17:33:04 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2L1X2KO004981 for ; Sat, 20 Mar 2004 17:33:02 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2L1X2gg004980 for linux-xfs@oss.sgi.com; Sat, 20 Mar 2004 17:33:02 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2L1X0KQ004952 for ; Sat, 20 Mar 2004 17:33:00 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2L0pFYO003880; Sat, 20 Mar 2004 16:51:15 -0800 Date: Sat, 20 Mar 2004 16:51:15 -0800 Message-Id: <200403210051.i2L0pFYO003880@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 319] wishlist: allow shrinking of XFS X-Bugzilla-Reason: AssignedTo X-archive-position: 2517 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 387 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=319 brian@minton.name changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|High |Low ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Mar 20 17:33:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 20 Mar 2004 17:33:04 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2L1X2KO004982 for ; Sat, 20 Mar 2004 17:33:02 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2L1X2Ca004979 for linux-xfs@oss.sgi.com; Sat, 20 Mar 2004 17:33:02 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2L1X0KU004952 for ; Sat, 20 Mar 2004 17:33:00 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2L0oseZ003869; Sat, 20 Mar 2004 16:50:54 -0800 Date: Sat, 20 Mar 2004 16:50:54 -0800 Message-Id: <200403210050.i2L0oseZ003869@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 319] New: wishlist: allow shrinking of XFS X-Bugzilla-Reason: AssignedTo X-archive-position: 2518 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 688 Lines: 27 http://oss.sgi.com/bugzilla/show_bug.cgi?id=319 Summary: wishlist: allow shrinking of XFS Product: Linux XFS Version: unspecified Platform: Other OS/Version: Linux Status: NEW Severity: enhancement Priority: High Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: brian@minton.name I would like to be able to shrink XFS filesystems. This is useful for repartitioning or when using a volume management system. Thanks, Brian Minton ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Mar 20 17:58:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 20 Mar 2004 17:58:18 -0800 (PST) Received: from mail.ocs.com.au (pr-117-210.ains.net.au [202.147.117.210] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2L1wEKO006459 for ; Sat, 20 Mar 2004 17:58:15 -0800 Received: from ocs3.ocs.com.au (ocs3.ocs.com.au [192.168.255.3]) by mail.ocs.com.au (Postfix) with ESMTP id BCCAF1800A2; Sun, 21 Mar 2004 12:58:07 +1100 (EST) Received: by ocs3.ocs.com.au (Postfix, from userid 16331) id A7103C00AE; Sun, 21 Mar 2004 12:57:45 +1100 (EST) Received: from ocs3.ocs.com.au (localhost [127.0.0.1]) by ocs3.ocs.com.au (Postfix) with ESMTP id A4695140089; Sun, 21 Mar 2004 12:57:45 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Rens Houben Cc: linux-xfs@oss.sgi.com Subject: Re: Kernel oops in XFS, kernel 2.6.4 In-reply-to: Your message of "Sat, 20 Mar 2004 12:09:31 BST." <20040320110931.GA19008@seiryuu.systemec.nl> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Date: Sun, 21 Mar 2004 12:57:44 +1100 Message-ID: <27377.1079834264@ocs3.ocs.com.au> Content-Transfer-Encoding: 8bit X-archive-position: 2519 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 353 Lines: 7 On Sat, 20 Mar 2004 12:09:31 +0100, Rens Houben wrote: >Mar 20 11:14:56 seiryuu kernel: Unable to handle kernel paging request at virtual address 6b6b6d57 >Mar 20 11:14:56 seiryuu kernel: eax: 6b6b6b6b ebx: 6b6b6b6b ecx: e33a5270 edx: 00000001 Repeated 0x6b is POISON_FREE. A slab has been used after being freed. From owner-linux-xfs@oss.sgi.com Sat Mar 20 19:53:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 20 Mar 2004 19:53:57 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2L3rrKO009794 for ; Sat, 20 Mar 2004 19:53:54 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 34C73FB839; Sat, 20 Mar 2004 21:53:51 -0600 (CST) Date: Sat, 20 Mar 2004 19:53:51 -0800 From: Chris Wedgwood To: linux-xfs@oss.sgi.com Subject: Re: 2.6.4 can't mount root xfs Message-ID: <20040321035351.GA4143@dingdong.cryptoapps.com> References: <20040316193914.GA1564@palkovic.org> <20040316194423.A4914@infradead.org> <20040318191523.GA1592@palkovic.org> <20040320054219.GA1936@palkovic.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040320054219.GA1936@palkovic.org> Content-Transfer-Encoding: 8bit X-archive-position: 2520 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 710 Lines: 22 On Fri, Mar 19, 2004 at 11:42:19PM -0600, John Palkovic wrote: > CONFIG_PARTITION_ADVANCED=y > CONFIG_MSDOS_PARTITION=y That's bogus. The default's for x86 will build MSDOS partition support with CONFIG_MSDOS_PARTITION undefined. > The strange thing is that this only seems to be necessary when root > is formatted as an XFS partition. If I format it, e.g., as ext3, > then I can boot with a 2.6.4 kernel that does not have these two > options set. With 2.6.3, they don't need to be set. Something else is going on. I have plenty of machines which boot of XFS filesystems and I never enable CONFIG_MSDOS_PARTITION=y. I missed the original problem but I'm sure something else is going on here. --cw From owner-linux-xfs@oss.sgi.com Sat Mar 20 19:57:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 20 Mar 2004 19:57:45 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2L3viKO010303 for ; Sat, 20 Mar 2004 19:57:44 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2L3viML010302 for linux-xfs@oss.sgi.com; Sat, 20 Mar 2004 19:57:44 -0800 Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2L3vdKO010281; Sat, 20 Mar 2004 19:57:39 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 5D4D6FB839; Sat, 20 Mar 2004 21:57:38 -0600 (CST) Date: Sat, 20 Mar 2004 19:57:38 -0800 From: Chris Wedgwood To: bugzilla-daemon@oss.sgi.com Cc: xfs-master@oss.sgi.com, brian@minton.name Subject: Re: [Bug 319] New: wishlist: allow shrinking of XFS Message-ID: <20040321035738.GB4143@dingdong.cryptoapps.com> References: <200403210050.i2L0oseZ003869@oss.sgi.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403210050.i2L0oseZ003869@oss.sgi.com> Content-Transfer-Encoding: 8bit X-archive-position: 2521 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 402 Lines: 10 On Sat, Mar 20, 2004 at 04:50:54PM -0800, bugzilla-daemon@oss.sgi.com wrote: > I would like to be able to shrink XFS filesystems. This is useful > for repartitioning or when using a volume management system. FWIW this is a fair amount of work and potentially will break some things. I'm not entirely sure it's worth considering as people tend to grow filesystems much more often the shrink them. From owner-linux-xfs@oss.sgi.com Sun Mar 21 06:03:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 21 Mar 2004 06:03:28 -0800 (PST) Received: from relay03.roc.ny.frontiernet.net (relay03.roc.ny.frontiernet.net [66.133.131.36]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2LE3OKO009766 for ; Sun, 21 Mar 2004 06:03:25 -0800 Received: (qmail 6212 invoked from network); 21 Mar 2004 14:03:23 -0000 Received: from unknown (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay03.roc.ny.frontiernet.net (FrontierMTA 2.3.7b) with SMTP for ; 21 Mar 2004 14:03:23 -0000 Message-ID: <405DA075.2080508@xfs.org> Date: Sun, 21 Mar 2004 08:02:29 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rens Houben CC: linux-xfs@oss.sgi.com, kaos@sgi.com Subject: Re: Kernel oops in XFS, kernel 2.6.4 References: <27377.1079834264@ocs3.ocs.com.au> In-Reply-To: <27377.1079834264@ocs3.ocs.com.au> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2522 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1082 Lines: 39 Keith Owens wrote: > On Sat, 20 Mar 2004 12:09:31 +0100, > Rens Houben wrote: > >>Mar 20 11:14:56 seiryuu kernel: Unable to handle kernel paging request at virtual address 6b6b6d57 >>Mar 20 11:14:56 seiryuu kernel: eax: 6b6b6b6b ebx: 6b6b6b6b ecx: e33a5270 edx: 00000001 > > > Repeated 0x6b is POISON_FREE. A slab has been used after being freed. > Which is somewhat scary, the oops happened here; void xfs_trans_unlocked_item( xfs_mount_t *mp, xfs_log_item_t *lip) { xfs_log_item_t *min_lip; /* * If we're forcibly shutting down, we may have * unlocked log items arbitrarily. The last thing * we want to do is to move the tail of the log * over some potentially valid data. */ if (!(lip->li_flags & XFS_LI_IN_AIL) || XFS_FORCED_SHUTDOWN(mp)) { ^^^^^^^^^^^^^^^^^^^ return; } Which makes it look like the mount structure has been freed. I notice the kernel is tainted, what was loaded? Steve From owner-linux-xfs@oss.sgi.com Sun Mar 21 15:51:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 21 Mar 2004 15:51:25 -0800 (PST) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2LNooKO006790 for ; Sun, 21 Mar 2004 15:50:51 -0800 Received: from broadpark.no (8.80-202-249.nextgentel.com [80.202.249.8]) by mail.broadpark.no (Postfix) with ESMTP id C8E1E7D9F for ; Mon, 22 Mar 2004 00:13:30 +0100 (MET) Message-ID: <405E219A.7080607@broadpark.no> Date: Mon, 22 Mar 2004 00:13:30 +0100 From: Kjell Randa User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Kernel oops in 2.4.22-1.2174.nptl_37.rhfc1.atsmp Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 2523 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Kjell.Randa@broadpark.no Precedence: bulk X-list: linux-xfs Content-Length: 6692 Lines: 153 Hi, I have been using XFS for more than two years without any problems, but lately I have started to get oops messages during time of heavy I/O load. The system survives and seems healty afterwords. This may be related to upgrade to the current kernel. System is a dual P3 866 MHz on av Via board using 4 Western Digital ide disks (2x160 Mb + 2x80GB) connect to a IDE PCI controller from HighPoint (Rocket133 with a Silicon Image chip SiI680) The disks are configured in raid1 (software), lvm and filesystems formatted with XFS. System is running Fedore Core1 with kernel downloaded from http://atrpms.physik.fu-berlin.de/dist/fc1/ This kernel conains the following patches: * base kernel sources: Taken from Fedora Core 1 * XFS: merged patches found in 1.3.1 * i2c-2.8.4 and lm_sensors-2.8.4. You should also get the updated userland tools and updated kernel modules. * Linux Extended Attributes and ACLs 0.8.65. * LVM 1.0.7 (courtesy of Komoriya Takeru) * v4l2-api (from http://bytesex.org/v4l/) * PlanetCCRMA caps patches: capabilities, drm low latency and others. * linux-ntfs 2.1.4c * bootsplash kernet is tainted by the Nividia binary driver. I am not shure if this is a XFS problems or could be related to some other patches (lvm), but not beeing a kernel hacker I hope somebody can take take look on the ksymoops output and give their opinion. ksymoops 2.4.5 on i686 2.4.22-1.2174.nptl_37.rhfc1.atsmp. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.22-1.2174.nptl_37.rhfc1.atsmp/ (default) -m /boot/System.map-2.4.22-1.2174.nptl_37.rhfc1.atsmp (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Error (expand_objects): cannot stat(/lib/ext3.o) for ext3 ksymoops: No such file or directory Error (expand_objects): cannot stat(/lib/jbd.o) for jbd ksymoops: No such file or directory Error (expand_objects): cannot stat(/lib/raid1.o) for raid1 ksymoops: No such file or directory Error (expand_objects): cannot stat(/lib/lvm-mod.o) for lvm-mod ksymoops: No such file or directory Warning (compare_maps): ksyms_base symbol dmi_broken_R__ver_dmi_broken not found in System.map. Ignoring ksyms_base entry Warning (map_ksym_to_module): cannot match loaded module ext3 to a unique module object. Trace may not be reliable. Mar 21 04:07:16 eagle nmbd[1089]: Got SIGHUP dumping debug info. Mar 21 04:46:17 eagle kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000006 Mar 21 04:46:17 eagle kernel: f0a00b70 Mar 21 04:46:17 eagle kernel: *pde = 00000000 Mar 21 04:46:17 eagle kernel: Oops: 0000 Mar 21 04:46:17 eagle kernel: CPU: 1 Mar 21 04:46:17 eagle kernel: EIP: 0060:[] Tainted: P Using defaults from ksymoops -t elf32-i386 -a i386 Mar 21 04:46:17 eagle kernel: EFLAGS: 00010256 Mar 21 04:46:17 eagle kernel: eax: 00000000 ebx: 00000002 ecx: c9325dbc edx: ffffffff Mar 21 04:46:17 eagle kernel: esi: ec557900 edi: 00000000 ebp: 00000000 esp: c9325d84 Mar 21 04:46:17 eagle kernel: ds: 0068 es: 0068 ss: 0068 Mar 21 04:46:17 eagle kernel: Process f-prot (pid: 28833, stackpage=c9325000) Mar 21 04:46:17 eagle kernel: Stack: df460b14 00000000 00000000 00001000 00000001 c9325dc0 c9325dbc d2a01380 Mar 21 04:46:17 eagle kernel: ef85b000 00000246 d2a01394 00000002 ffffffff ffffffff 00000001 ffffffff Mar 21 04:46:17 eagle kernel: ffffffff 00000000 00000000 00000000 00000000 00001000 00000002 ec557900 Mar 21 04:46:17 eagle kernel: Call Trace: [] linvfs_get_block [xfs] 0x37 (0xc9325df0) Mar 21 04:46:17 eagle kernel: [] block_read_full_page [kernel] 0x2b6 (0xc9325e0c) Mar 21 04:46:18 eagle kernel: [] do_generic_file_read [kernel] 0x239 (0xc9325e70) Mar 21 04:46:18 eagle kernel: [] linvfs_get_block [xfs] 0x0 (0xc9325e78) Mar 21 04:46:18 eagle kernel: [] file_read_actor [kernel] 0x0 (0xc9325ea0) Mar 21 04:46:18 eagle kernel: [] generic_file_new_read [kernel] 0xc5 (0xc9325ec0) Mar 21 04:46:18 eagle kernel: [] file_read_actor [kernel] 0x0 (0xc9325ed0) Mar 21 04:46:18 eagle kernel: [] dput [kernel] 0x30 (0xc9325ed8) Mar 21 04:46:18 eagle kernel: [] generic_file_read [kernel] 0x2f (0xc9325f0c) Mar 21 04:46:18 eagle kernel: [] xfs_read [xfs] 0x133 (0xc9325f24) Mar 21 04:46:18 eagle kernel: [] linvfs_read [xfs] 0x72 (0xc9325f64) Mar 21 04:46:18 eagle kernel: [] sys_read [kernel] 0x97 (0xc9325f94) Mar 21 04:46:18 eagle kernel: [] system_call [kernel] 0x33 (0xc9325fc0) Mar 21 04:46:18 eagle kernel: Code: 0f b7 40 06 66 89 46 0c 8b 44 24 7c 85 c0 74 2e f7 46 18 11 >>EIP; f0a00b70 <[xfs]linvfs_get_block_core+1c0/270> <===== >>ecx; c9325dbc <_end+8e63944/3034cbe8> >>edx; ffffffff >>esi; ec557900 <_end+2c095488/3034cbe8> >>esp; c9325d84 <_end+8e6390c/3034cbe8> Trace; f0a00c57 <[xfs]linvfs_get_block+37/40> Trace; c0153f26 Trace; c013e179 Trace; f0a00c20 <[xfs]linvfs_get_block+0/40> Trace; c013e7c0 Trace; c013e985 Trace; c013e7c0 Trace; c0167b20 Trace; c013eaaf Trace; f0a06e53 <[xfs]xfs_read+133/2f0> Trace; f0a015e2 <[xfs]linvfs_read+72/f0> Trace; c01504f7 Trace; c0109b27 Code; f0a00b70 <[xfs]linvfs_get_block_core+1c0/270> 00000000 <_EIP>: Code; f0a00b70 <[xfs]linvfs_get_block_core+1c0/270> <===== 0: 0f b7 40 06 movzwl 0x6(%eax),%eax <===== Code; f0a00b74 <[xfs]linvfs_get_block_core+1c4/270> 4: 66 89 46 0c mov %ax,0xc(%esi) Code; f0a00b78 <[xfs]linvfs_get_block_core+1c8/270> 8: 8b 44 24 7c mov 0x7c(%esp,1),%eax Code; f0a00b7c <[xfs]linvfs_get_block_core+1cc/270> c: 85 c0 test %eax,%eax Code; f0a00b7e <[xfs]linvfs_get_block_core+1ce/270> e: 74 2e je 3e <_EIP+0x3e> Code; f0a00b80 <[xfs]linvfs_get_block_core+1d0/270> 10: f7 46 18 11 00 00 00 testl $0x11,0x18(%esi) 3 warnings and 4 errors issued. Results may not be reliable. From owner-linux-xfs@oss.sgi.com Sun Mar 21 19:45:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 21 Mar 2004 19:45:18 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2M3jDKO016617 for ; Sun, 21 Mar 2004 19:45:15 -0800 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1B5GNE-00057R-00 for ; Mon, 22 Mar 2004 04:45:12 +0100 Received: from ip-63-246-221-143-cust.roc.netacc.net ([63.246.221.143]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Mar 2004 04:45:12 +0100 Received: from jasonp by ip-63-246-221-143-cust.roc.netacc.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Mar 2004 04:45:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: Jason Parker-Burlingham Subject: xfsrestore: "is a directory: discarding ino" Date: Sun, 21 Mar 2004 22:42:33 -0500 Message-ID: <878yhtpmxi.fsf@freezer.burling> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip-63-246-221-143-cust.roc.netacc.net User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) Cancel-Lock: sha1:KMTHcDkvjnhXJ/b/mtT2smhkqhE= Content-Transfer-Encoding: 8bit X-archive-position: 2524 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonp@panix.com Precedence: bulk X-list: linux-xfs Content-Length: 1496 Lines: 30 I'm running a 2.4.23 kernel from CVS with LVM1 patches applied. I'm trying to move an XFS filesystem from one logical volume to another using xfsrestore 2.2.18 and not having a lot of success: # xfsdump -J - /mnt | xfsrestore -J - /pivot [...] xfsrestore: reading directories xfsdump: dumping non-directory files xfsrestore: 2694 directories and 69903 entries processed xfsrestore: directory post-processing xfsrestore: WARNING: mkdir failed: No such file or directory xfsrestore: WARNING: mkdir failed: No such file or directory xfsrestore: WARNING: mkdir failed: No such file or directory xfsrestore: WARNING: mkdir failed: No such file or directory xfsrestore: WARNING: unable to set non-root extended attribute for : No such file or directory (2) xfsrestore: WARNING: unable to set secure extended attribute for : No such file or directory (2) xfsrestore: restoring non-directory files xfsrestore: WARNING: open of ///gconf.xml.defaults/schemas///UI/ failed: No such file or directory: discarding ino 135 [...] xfsrestore: WARNING: open of /Kodak Pictures// failed: Is a directory: discarding ino 10811 The point at which the errors occur does not appear to be repeatable. If I let the dump/restore run to completion, xfsrestore reports success and the filesystem appears to be complete, but directory permissions are set to 000. Is there some other option I should be passing to xfsrestore? -- http://panix.com/~jasonp?BabyPictures From owner-linux-xfs@oss.sgi.com Mon Mar 22 07:26:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Mar 2004 07:26:40 -0800 (PST) Received: from macnews.de (webmail.macnews.de [81.92.6.138]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2MFQYKO028724 for ; Mon, 22 Mar 2004 07:26:35 -0800 Received: from [80.140.47.84] (account pl10697 HELO [192.168.1.42]) by macnews.de (CommuniGate Pro SMTP 4.1.8) with ESMTP id 24121378 for linux-xfs@oss.sgi.com; Mon, 22 Mar 2004 16:26:27 +0100 From: Tobias Eichert To: linux-xfs@oss.sgi.com Subject: Recommened XFS settings for a laptop Date: Mon, 22 Mar 2004 16:26:41 +0100 User-Agent: KMail/1.6.1 MIME-Version: 1.0 Content-Disposition: inline Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Message-Id: <200403221626.41593.te@macnews.de> X-archive-position: 2525 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: te@macnews.de Precedence: bulk X-list: linux-xfs Content-Length: 1303 Lines: 32 Hello XFS ML, I use XFS on an IBM Thinkpad with a 60GB harddisk. My question is: Are there any recommended settings for using XFS on a laptop? Last time I started an OpenGL app in fullscreen mode I experienced a system freeze (couldn't even switch to a console to kill that process) and so I had to do a system restart without unmounting my partitions in a friendly manner. ;) After everything was up and running again I noticed that KDE had a different look&feel - for example, colors and font sizes changed to their default values (which makes me believe that some of the config files got corrupted and KDE using the default ones). This assumption is stressed by the fact that, on a previous installation and system freeze I indeed had corrupted kde config files (using XFS). Are there any recommeded settings (especially mount and sysctl options) for XFS (on a laptop)? Note that this system freeze isn't really laptop specific (why should it be? ;)) but if there are XFS-on-a-laptop users on this list I'd really appreciate some hints, tipps and tricks for running XFS as stable as possible. What about journalling / ordered data modes - commit intervalls, noatime, etc.. ? My kernel: 2.6.4 (vanilla) Keep up the good work on XFS! Tobias ps: ..and sorry for my bad English. ;) From owner-linux-xfs@oss.sgi.com Mon Mar 22 10:14:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Mar 2004 10:14:34 -0800 (PST) Received: from web41409.mail.yahoo.com (web41409.mail.yahoo.com [66.218.93.75]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2MIEJKO005285 for ; Mon, 22 Mar 2004 10:14:19 -0800 Message-ID: <20040322181414.20891.qmail@web41409.mail.yahoo.com> Received: from [61.1.106.146] by web41409.mail.yahoo.com via HTTP; Mon, 22 Mar 2004 10:14:14 PST Date: Mon, 22 Mar 2004 10:14:14 -0800 (PST) From: ankur mattoo Subject: problem with setxattr To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2526 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: coolpal53@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 644 Lines: 31 hi okay im trying to use setxattr and my simple prog is giving an invalid argument error on stracing!! main() { char *buff; size_t t=getxattr("ankur1","system.posix_acl_access",buff,0); buff=(char *)malloc(t); getxattr("ankur1","system.posix_acl_access",buff,0); if(setxattr("ankur1","system.posix_acl_access",buff,t,0)); perror("Error"); } i am using linux 2.4.23 with EA patch. setfacl and getfacl all these commands are working properly. Can anyone help me with this !! -Ankur BE computers __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html From owner-linux-xfs@oss.sgi.com Mon Mar 22 10:33:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Mar 2004 10:33:12 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2MIXAKO006294 for ; Mon, 22 Mar 2004 10:33:10 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2MIX9H8006293 for linux-xfs@oss.sgi.com; Mon, 22 Mar 2004 10:33:09 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2MIX8KQ006279 for ; Mon, 22 Mar 2004 10:33:08 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2MI4Cm0004566; Mon, 22 Mar 2004 10:04:12 -0800 Date: Mon, 22 Mar 2004 10:04:12 -0800 Message-Id: <200403221804.i2MI4Cm0004566@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 317] Kernel error messages using XFS X-Bugzilla-Reason: AssignedTo X-archive-position: 2527 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1336 Lines: 36 http://oss.sgi.com/bugzilla/show_bug.cgi?id=317 sandeen@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From sandeen@sgi.com 2004-22-03 10:04 PDT ------- In general, anything over 1T in the 2.4 kernels is not safe - the core kernel code is rife with ints holding sector addresses, which will leave you with corruption over 1T. The XFS code itself is fine, but lots of device drivers & even core I/O code doesn't cope with large filesystems. http://www.gelato.unsw.edu.au/IA64wiki/LargeBlockDevices "In effect under early 2.5 (2.5.x<28) and 2.4 linux, the maximum file system size is about 1TB." Other filesystems may appear to work, but depending on their allocation scheme and error-checking, they may not hit the errors so quickly. XFS allocates round-robin style around the allocation groups, so you will start hitting high sectors very quickly. We really can't support >1T in 2.4; if you need this I'd suggest using 2.6 kernels with CONFIG_LBD enabled. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Mar 22 11:49:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Mar 2004 11:50:02 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2MJnvKO009584 for ; Mon, 22 Mar 2004 11:49:57 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2MJnvNT009583 for linux-xfs@oss.sgi.com; Mon, 22 Mar 2004 11:49:57 -0800 Received: from saytrin.hq.k1024.org ([62.217.245.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2MJnbKO009548; Mon, 22 Mar 2004 11:49:45 -0800 Received: by saytrin.hq.k1024.org (Postfix, from userid 4004) id BB7AE508; Mon, 22 Mar 2004 21:49:23 +0200 (EET) Date: Mon, 22 Mar 2004 21:49:23 +0200 From: Iustin Pop To: Chris Wedgwood Cc: bugzilla-daemon@oss.sgi.com, xfs-master@oss.sgi.com, brian@minton.name Subject: Re: [Bug 319] New: wishlist: allow shrinking of XFS Message-ID: <20040322194923.GA5404@saytrin.hq.k1024.org> References: <200403210050.i2L0oseZ003869@oss.sgi.com> <20040321035738.GB4143@dingdong.cryptoapps.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040321035738.GB4143@dingdong.cryptoapps.com> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.5.1+cvs20040105i Content-Transfer-Encoding: 8bit X-archive-position: 2528 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs Content-Length: 672 Lines: 18 On Sat, Mar 20, 2004 at 07:57:38PM -0800, Chris Wedgwood wrote: > On Sat, Mar 20, 2004 at 04:50:54PM -0800, bugzilla-daemon@oss.sgi.com wrote: > > > I would like to be able to shrink XFS filesystems. This is useful > > for repartitioning or when using a volume management system. > > FWIW this is a fair amount of work and potentially will break some > things. I'm not entirely sure it's worth considering as people tend > to grow filesystems much more often the shrink them. Couldn't this be implemented by taking offline the last AG(s)? This would be similar to growing, where you add a (some) new AG(s) and put the online, just the reverse. Regards, Iustin Pop From owner-linux-xfs@oss.sgi.com Mon Mar 22 12:07:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Mar 2004 12:07:22 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2MK7DKO010595 for ; Mon, 22 Mar 2004 12:07:13 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2MK7ClX010592 for linux-xfs@oss.sgi.com; Mon, 22 Mar 2004 12:07:12 -0800 Received: from localhost.localdomain (outgoingmail.adic.com [63.81.117.28]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2MK7BKO010579; Mon, 22 Mar 2004 12:07:11 -0800 Received: from xfs.org (jen [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i2MK2YTo024310; Mon, 22 Mar 2004 14:02:37 -0600 Message-ID: <405F465A.7020104@xfs.org> Date: Mon, 22 Mar 2004 14:02:34 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iustin Pop CC: Chris Wedgwood , bugzilla-daemon@oss.sgi.com, xfs-master@oss.sgi.com, brian@minton.name Subject: Re: [Bug 319] New: wishlist: allow shrinking of XFS References: <200403210050.i2L0oseZ003869@oss.sgi.com> <20040321035738.GB4143@dingdong.cryptoapps.com> <20040322194923.GA5404@saytrin.hq.k1024.org> In-Reply-To: <20040322194923.GA5404@saytrin.hq.k1024.org> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2529 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1877 Lines: 46 Iustin Pop wrote: > On Sat, Mar 20, 2004 at 07:57:38PM -0800, Chris Wedgwood wrote: > >>On Sat, Mar 20, 2004 at 04:50:54PM -0800, bugzilla-daemon@oss.sgi.com wrote: >> >> >>>I would like to be able to shrink XFS filesystems. This is useful >>>for repartitioning or when using a volume management system. >> >>FWIW this is a fair amount of work and potentially will break some >>things. I'm not entirely sure it's worth considering as people tend >>to grow filesystems much more often the shrink them. > > > Couldn't this be implemented by taking offline the last AG(s)? This > would be similar to growing, where you add a (some) new AG(s) and put > the online, just the reverse. > > > Regards, > Iustin Pop > Its a little more complex than that, when you grow, you add empty space to the fs, when you shrink, you have to move files out of the space being removed. So, lets say you want to chop the last 4 allocation groups off an xfs filesystem. You need to find all the inodes within this space, and move them somewhere else. You also need to find all the files which have contents in this space - which is not the same as the inodes being in this space, and relocate the contents of those extents back down to somewhere else in the fs. Note that the extents you have to deal with are not just file data..... Any extended attributes need replicating, symlink contents, directory contents etc (you could have a directory whose inode is not in the space being freed, and which points at no inodes in the space being freed, but which has disk blocks in the space being freed). The only way to really do this is a complete tree walk of all the metadata in the filesystem looking for any inode which has a metadata or data block in the allocation groups being freed, and reallocate that space elsewhere. Not quite just the reverse of adding more free space ;-) Steve From owner-linux-xfs@oss.sgi.com Mon Mar 22 12:29:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Mar 2004 12:29:21 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2MKTFKO014894 for ; Mon, 22 Mar 2004 12:29:15 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2MKTFhw014893 for linux-xfs@oss.sgi.com; Mon, 22 Mar 2004 12:29:15 -0800 Received: from saytrin.hq.k1024.org ([62.217.245.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2MKT1KO014873; Mon, 22 Mar 2004 12:29:04 -0800 Received: by saytrin.hq.k1024.org (Postfix, from userid 4004) id 24B76508; Mon, 22 Mar 2004 22:28:51 +0200 (EET) Date: Mon, 22 Mar 2004 22:28:51 +0200 From: Iustin Pop To: Steve Lord Cc: Chris Wedgwood , bugzilla-daemon@oss.sgi.com, xfs-master@oss.sgi.com, brian@minton.name Subject: Re: [Bug 319] New: wishlist: allow shrinking of XFS Message-ID: <20040322202851.GB5404@saytrin.hq.k1024.org> References: <200403210050.i2L0oseZ003869@oss.sgi.com> <20040321035738.GB4143@dingdong.cryptoapps.com> <20040322194923.GA5404@saytrin.hq.k1024.org> <405F465A.7020104@xfs.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <405F465A.7020104@xfs.org> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.5.1+cvs20040105i Content-Transfer-Encoding: 8bit X-archive-position: 2530 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs Content-Length: 660 Lines: 23 On Mon, Mar 22, 2004 at 02:02:34PM -0600, Steve Lord wrote: > Its a little more complex than that, when you grow, you add empty space to > the fs, when you shrink, you have to move files out of the space being > removed. > > [.......] > > Not quite just the reverse of adding more free space ;-) > > Steve > Ahem, yes, uh, I imagined the space would be empty (magically). I'll make one more try, however: based on the model of xfs_fsr, couldn't the files (not the dirs) be moved in other AGs? This of course would leave the directories and maybe the inodes in the to-be-freed AGs. Just a mental exercise :) Thanks for the nice explanation. Iustin Pop From owner-linux-xfs@oss.sgi.com Mon Mar 22 13:27:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Mar 2004 13:27:35 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2MLRRKO017205 for ; Mon, 22 Mar 2004 13:27:27 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2MLRKUo030073 for ; Mon, 22 Mar 2004 15:27:21 -0600 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA05329; Tue, 23 Mar 2004 08:27:18 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2MLRDFx592005; Tue, 23 Mar 2004 08:27:14 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i2MLQbfk000738; Tue, 23 Mar 2004 08:26:37 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i2MLQZYu000736; Tue, 23 Mar 2004 08:26:35 +1100 Date: Tue, 23 Mar 2004 08:26:35 +1100 From: Nathan Scott To: Jason Parker-Burlingham , Mandy Kirkconnell Cc: linux-xfs@oss.sgi.com Subject: Re: xfsrestore: "is a directory: discarding ino" Message-ID: <20040322212635.GA699@frodo> References: <878yhtpmxi.fsf@freezer.burling> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <878yhtpmxi.fsf@freezer.burling> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2531 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1839 Lines: 41 On Sun, Mar 21, 2004 at 10:42:33PM -0500, Jason Parker-Burlingham wrote: > I'm running a 2.4.23 kernel from CVS with LVM1 patches applied. I'm > trying to move an XFS filesystem from one logical volume to another > using xfsrestore 2.2.18 and not having a lot of success: > > # xfsdump -J - /mnt | xfsrestore -J - /pivot > [...] > xfsrestore: reading directories > xfsdump: dumping non-directory files > xfsrestore: 2694 directories and 69903 entries processed > xfsrestore: directory post-processing > xfsrestore: WARNING: mkdir failed: No such file or directory > xfsrestore: WARNING: mkdir failed: No such file or directory > xfsrestore: WARNING: mkdir failed: No such file or directory > xfsrestore: WARNING: mkdir failed: No such file or directory > xfsrestore: WARNING: unable to set non-root extended attribute for : No such file or directory (2) > xfsrestore: WARNING: unable to set secure extended attribute for : No such file or directory (2) > xfsrestore: restoring non-directory files > xfsrestore: WARNING: open of ///gconf.xml.defaults/schemas///UI/ failed: No such file or directory: discarding ino 135 > [...] > xfsrestore: WARNING: open of /Kodak Pictures// failed: Is a directory: discarding ino 10811 > > The point at which the errors occur does not appear to be repeatable. > > If I let the dump/restore run to completion, xfsrestore reports > success and the filesystem appears to be complete, but directory > permissions are set to 000. > > Is there some other option I should be passing to xfsrestore? Don't think so, looks like a bug. Almost looks like the filename string is null for some reason, somewhere in restore (those mkdir errors, etc, above - look like they're trying to print filenames). Does this ring any bells Mandy? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Mar 22 13:43:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Mar 2004 13:43:49 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2MLhkKO018490 for ; Mon, 22 Mar 2004 13:43:46 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2MNkNAV013329 for ; Mon, 22 Mar 2004 15:46:24 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA05666; Tue, 23 Mar 2004 08:43:38 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2MLhXFx591604; Tue, 23 Mar 2004 08:43:34 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i2MLgvfk000801; Tue, 23 Mar 2004 08:42:58 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i2MLgvmj000799; Tue, 23 Mar 2004 08:42:57 +1100 Date: Tue, 23 Mar 2004 08:42:57 +1100 From: Nathan Scott To: ankur mattoo Cc: linux-xfs@oss.sgi.com Subject: Re: problem with setxattr Message-ID: <20040322214257.GB699@frodo> References: <20040322181414.20891.qmail@web41409.mail.yahoo.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040322181414.20891.qmail@web41409.mail.yahoo.com> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2532 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 517 Lines: 25 On Mon, Mar 22, 2004 at 10:14:14AM -0800, ankur mattoo wrote: > hi > okay im trying to use setxattr and my simple prog is > giving an invalid argument error on stracing!! > > main() > { > char *buff; > size_t > t=getxattr("ankur1","system.posix_acl_access",buff,0); > buff=(char *)malloc(t); > getxattr("ankur1","system.posix_acl_access",buff,0); Last parameter on the line above needs to be 't', not 0. > if(setxattr("ankur1","system.posix_acl_access",buff,t,0)); > perror("Error"); > } > cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Mar 22 14:30:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Mar 2004 14:30:22 -0800 (PST) Received: from amber.he.net (amber.he.net [216.218.172.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2MMUGKO020048 for ; Mon, 22 Mar 2004 14:30:16 -0800 Received: from stinkpad ([208.35.40.2] (may be forged)) by amber.he.net (8.8.6p2003-03-31/8.8.2) with ESMTP id OAA12802 for ; Mon, 22 Mar 2004 14:30:22 -0800 Message-Id: <200403222230.OAA12802@amber.he.net> From: "Mike Young" To: Subject: External Journal and ACL Support Date: Mon, 22 Mar 2004 14:31:16 -0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 thread-index: AcQQVOqxlN7wA8fKQZaF26NwKV3GbQ== Content-Disposition: inline Content-type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 2533 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: myoung@wildernessvoice.com Precedence: bulk X-list: linux-xfs Content-Length: 1030 Lines: 38 Hi All, I'm running into a problem when I use the external journal option along with ACLs. Without ACLs, I can see a significant performance delta between the use of an internal journal and an external one. Under Netbench, the difference is as much 2x to 3x. So, I definitely want to use this capability. However, all of my testing was without ACLs being set. When I went back and turned ACLs, the performance turned upside down on me. Basically, the there is very little performance difference between internal or external journal. And, in some cases, the external journal is slower than the internal journal. Any tips on how I should configure the ACLs so as to not degrade performance? To set the journaling up for external placement, I'm using "mkfs.xfs /dev/md1 -l logdev=/dev/md0,size=10000b". For ACLs, I'm just using getfacl to store the acls in a file till I can reapply them to the new directories using "setfacl -set-file". Thanks for the help, -Mike [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Mar 22 14:41:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Mar 2004 14:41:32 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2MMfQKO020643 for ; Mon, 22 Mar 2004 14:41:26 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2MNgTiQ030437 for ; Mon, 22 Mar 2004 15:42:29 -0800 Received: from sgi.com (syntegra.americas.sgi.com [128.162.232.81]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2MMfJKe35798048; Mon, 22 Mar 2004 16:41:20 -0600 (CST) Message-ID: <405F6B77.70308@sgi.com> Date: Mon, 22 Mar 2004 16:40:55 -0600 From: Mandy Kirkconnell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Jason Parker-Burlingham CC: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: xfsrestore: "is a directory: discarding ino" References: <878yhtpmxi.fsf@freezer.burling> <20040322212635.GA699@frodo> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2534 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alkirkco@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2376 Lines: 50 Nathan Scott wrote: > On Sun, Mar 21, 2004 at 10:42:33PM -0500, Jason Parker-Burlingham wrote: > >>I'm running a 2.4.23 kernel from CVS with LVM1 patches applied. I'm >>trying to move an XFS filesystem from one logical volume to another >>using xfsrestore 2.2.18 and not having a lot of success: >> >> # xfsdump -J - /mnt | xfsrestore -J - /pivot >> [...] >> xfsrestore: reading directories >> xfsdump: dumping non-directory files >> xfsrestore: 2694 directories and 69903 entries processed >> xfsrestore: directory post-processing >> xfsrestore: WARNING: mkdir failed: No such file or directory >> xfsrestore: WARNING: mkdir failed: No such file or directory >> xfsrestore: WARNING: mkdir failed: No such file or directory >> xfsrestore: WARNING: mkdir failed: No such file or directory >> xfsrestore: WARNING: unable to set non-root extended attribute for : No such file or directory (2) >> xfsrestore: WARNING: unable to set secure extended attribute for : No such file or directory (2) >> xfsrestore: restoring non-directory files >> xfsrestore: WARNING: open of ///gconf.xml.defaults/schemas///UI/ failed: No such file or directory: discarding ino 135 >> [...] >> xfsrestore: WARNING: open of /Kodak Pictures// failed: Is a directory: discarding ino 10811 >> >>The point at which the errors occur does not appear to be repeatable. >> >>If I let the dump/restore run to completion, xfsrestore reports >>success and the filesystem appears to be complete, but directory >>permissions are set to 000. >> >>Is there some other option I should be passing to xfsrestore? > > > Don't think so, looks like a bug. Almost looks like the filename > string is null for some reason, somewhere in restore (those mkdir > errors, etc, above - look like they're trying to print filenames). > > Does this ring any bells Mandy? No, this is new to me. I agree that it looks like there are a bunch of null filename strings. Jason, you mentioned that the point of error doesn't seem to be consistent but it sounds like it's reproducible in the sense that you've seen this behaviour more than once. Is there anything unique or special about the data you're restoring? It looks like the FS may have extended attributes (non-root, secure, or both ??). I haven't been able to repro this yet so any additional info would be helpful. Mandy From owner-linux-xfs@oss.sgi.com Mon Mar 22 15:17:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Mar 2004 15:17:33 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2MNHSKO022861 for ; Mon, 22 Mar 2004 15:17:28 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id E4BD1FB839; Mon, 22 Mar 2004 17:17:20 -0600 (CST) Date: Mon, 22 Mar 2004 15:17:20 -0800 From: Chris Wedgwood To: Mike Young Cc: linux-xfs@oss.sgi.com Subject: Re: External Journal and ACL Support Message-ID: <20040322231720.GA20959@dingdong.cryptoapps.com> References: <200403222230.OAA12802@amber.he.net> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403222230.OAA12802@amber.he.net> Content-Transfer-Encoding: 8bit X-archive-position: 2535 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 418 Lines: 14 On Mon, Mar 22, 2004 at 02:31:16PM -0800, Mike Young wrote: > To set the journaling up for external placement, I'm using "mkfs.xfs > /dev/md1 -l logdev=/dev/md0,size=10000b". For ACLs, I'm just using > getfacl to store the acls in a file till I can reapply them to the > new directories using "setfacl -set-file". Do larger inodes help? I wonder is with ACLs you're not becoming seek-bound on metadata. --cw From owner-linux-xfs@oss.sgi.com Mon Mar 22 15:27:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Mar 2004 15:27:14 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2MNRBKO023574 for ; Mon, 22 Mar 2004 15:27:11 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2N0SDiQ000780 for ; Mon, 22 Mar 2004 16:28:14 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA07617; Tue, 23 Mar 2004 10:27:03 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2MNQxFx537659; Tue, 23 Mar 2004 10:26:59 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i2MNQNfk001179; Tue, 23 Mar 2004 10:26:23 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i2MNQMMD001177; Tue, 23 Mar 2004 10:26:22 +1100 Date: Tue, 23 Mar 2004 10:26:22 +1100 From: Nathan Scott To: Mike Young Cc: linux-xfs@oss.sgi.com Subject: Re: External Journal and ACL Support Message-ID: <20040322232622.GF699@frodo> References: <200403222230.OAA12802@amber.he.net> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403222230.OAA12802@amber.he.net> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2537 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1266 Lines: 34 On Mon, Mar 22, 2004 at 02:31:16PM -0800, Mike Young wrote: > Hi All, > > > > I'm running into a problem when I use the external journal option along with > ACLs. Without ACLs, I can see a significant performance delta between the > use of an internal journal and an external one. Under Netbench, the > difference is as much 2x to 3x. So, I definitely want to use this > capability. However, all of my testing was without ACLs being set. When I > went back and turned ACLs, the performance turned upside down on me. > Basically, the there is very little performance difference between internal > or external journal. And, in some cases, the external journal is slower > than the internal journal. > > > > Any tips on how I should configure the ACLs so as to not degrade > performance? Use larger inodes -- ie. the mkfs.xfs option -isize=512 (or greater), will allow the ACLs to be stored inline most of the time, and is a large performance win for this sort of workload. > To set the journaling up for external placement, I'm using "mkfs.xfs > /dev/md1 -l logdev=/dev/md0,size=10000b". For ACLs, I'm just using getfacl > to store the acls in a file till I can reapply them to the new directories > using "setfacl -set-file". cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Mar 22 15:27:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Mar 2004 15:27:11 -0800 (PST) Received: from amber.he.net (amber.he.net [216.218.172.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2MNR5KO023573 for ; Mon, 22 Mar 2004 15:27:07 -0800 Received: from stinkpad ([208.35.40.2] (may be forged)) by amber.he.net (8.8.6p2003-03-31/8.8.2) with ESMTP id PAA18295; Mon, 22 Mar 2004 15:27:10 -0800 Message-Id: <200403222327.PAA18295@amber.he.net> From: "Mike Young" To: "'Chris Wedgwood'" Cc: Subject: RE: External Journal and ACL Support Date: Mon, 22 Mar 2004 15:28:05 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20040322231720.GA20959@dingdong.cryptoapps.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 thread-index: AcQQY+v5xbrR+nN2TIaVjJ8JfR7+HQAAUOSg X-archive-position: 2536 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: myoung@wildernessvoice.com Precedence: bulk X-list: linux-xfs Content-Length: 781 Lines: 32 Hi Chris, That's an excellent question. My default is 1k right now. I'm going to give 2k a try. -Mike -----Original Message----- From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Chris Wedgwood Sent: Monday, March 22, 2004 3:17 PM To: Mike Young Cc: linux-xfs@oss.sgi.com Subject: Re: External Journal and ACL Support On Mon, Mar 22, 2004 at 02:31:16PM -0800, Mike Young wrote: > To set the journaling up for external placement, I'm using "mkfs.xfs > /dev/md1 -l logdev=/dev/md0,size=10000b". For ACLs, I'm just using > getfacl to store the acls in a file till I can reapply them to the > new directories using "setfacl -set-file". Do larger inodes help? I wonder is with ACLs you're not becoming seek-bound on metadata. --cw From owner-linux-xfs@oss.sgi.com Mon Mar 22 15:45:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Mar 2004 15:45:19 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2MNj9KO024748 for ; Mon, 22 Mar 2004 15:45:09 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2N0cDiQ001316 for ; Mon, 22 Mar 2004 16:38:13 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA07798; Tue, 23 Mar 2004 10:37:03 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2MNawFx594721; Tue, 23 Mar 2004 10:36:59 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i2MNaMfk001226; Tue, 23 Mar 2004 10:36:22 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i2MNaL1J001224; Tue, 23 Mar 2004 10:36:21 +1100 Date: Tue, 23 Mar 2004 10:36:21 +1100 From: Nathan Scott To: Mike Young Cc: "'Chris Wedgwood'" , linux-xfs@oss.sgi.com Subject: Re: External Journal and ACL Support Message-ID: <20040322233621.GG699@frodo> References: <20040322231720.GA20959@dingdong.cryptoapps.com> <200403222327.PAA18295@amber.he.net> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403222327.PAA18295@amber.he.net> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2538 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1358 Lines: 48 On Mon, Mar 22, 2004 at 03:28:05PM -0800, Mike Young wrote: > Hi Chris, > > That's an excellent question. My default is 1k right now. I'm going to > give 2k a try. Can you send your filesystem geometry (xfs_info output)? And any performance numbers you have for each of the different geometries you've tried would be good to see too. The difference moving from the default 256 byte inode to any larger inode size is where the big gains are seen, I wouldn't expect too much improvement going from 1k to 2k. Though it may help a bit for small directories with ACLs... (and small directories in general). cheers. > -----Original Message----- > From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com] On > Behalf Of Chris Wedgwood > Sent: Monday, March 22, 2004 3:17 PM > To: Mike Young > Cc: linux-xfs@oss.sgi.com > Subject: Re: External Journal and ACL Support > > On Mon, Mar 22, 2004 at 02:31:16PM -0800, Mike Young wrote: > > > To set the journaling up for external placement, I'm using "mkfs.xfs > > /dev/md1 -l logdev=/dev/md0,size=10000b". For ACLs, I'm just using > > getfacl to store the acls in a file till I can reapply them to the > > new directories using "setfacl -set-file". > > Do larger inodes help? I wonder is with ACLs you're not becoming > seek-bound on metadata. > > > > --cw > > > > > -- Nathan From owner-linux-xfs@oss.sgi.com Mon Mar 22 16:37:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Mar 2004 16:37:47 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2N0bfKO030906 for ; Mon, 22 Mar 2004 16:37:42 -0800 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1B5ZvH-0005V5-00 for ; Tue, 23 Mar 2004 01:37:40 +0100 Received: from ip-63-246-221-94-cust.roc.netacc.net ([63.246.221.94]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Mar 2004 01:37:39 +0100 Received: from jasonp by ip-63-246-221-94-cust.roc.netacc.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Mar 2004 01:37:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: Jason Parker-Burlingham Subject: Re: xfsrestore: "is a directory: discarding ino" Date: Mon, 22 Mar 2004 19:07:43 -0500 Message-ID: <87vfkwo27k.fsf@freezer.burling> References: <878yhtpmxi.fsf@freezer.burling> <20040322212635.GA699@frodo> <405F6B77.70308@sgi.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip-63-246-221-94-cust.roc.netacc.net In-Reply-To: <405F6B77.70308@sgi.com> (Mandy Kirkconnell's message of "Mon, 22 Mar 2004 16:40:55 -0600") User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) Cancel-Lock: sha1:0oBuopDwejmwFxqfAxZyPqcR800= Content-Transfer-Encoding: 8bit X-archive-position: 2539 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonp@panix.com Precedence: bulk X-list: linux-xfs Content-Length: 1732 Lines: 58 Mandy Kirkconnell writes: > Nathan Scott wrote: >> Don't think so, looks like a bug. Almost looks like the filename >> string is null for some reason, somewhere in restore (those mkdir >> errors, etc, above - look like they're trying to print filenames). >> >> Does this ring any bells Mandy? > > No, this is new to me. Uh-oh. > I agree that it looks like there are a bunch of null filename > strings. I thought of this, too. > Jason, you mentioned that the point of error doesn't seem to be > consistent but it sounds like it's reproducible in the sense that > you've seen this behaviour more than once. Happens every time I pipe xfsdump into xfsrestore. > Is there anything unique or special about the data you're restoring? It's on an lvm1 logical volume; there's only one physical volume in the group. I was trying to dump from an LVM snapshot, but I just tried $ sudo xfsdump -l0 -J - /home | sudo xfsrestore -J -t - and soon started seeing output like //mail/humbug/ /.samba-profile// //build/Class-Accessor-0.17// /// /// > It looks like the FS may have extended attributes (non-root, secure, > or both ??). I'm not sure. I don't believe I've set any myself. How can I tell for sure? (I looked briefly at the attr(1) manpage but didn't find it helpful. getfattr(1) doesn't reveal anything except for user.SGI_XFSDUMP_SKIP_FILE on temp directory (yes, it doesn't work; I know). How can I list root extended attributes? > I haven't been able to repro this yet so any additional info would > be helpful. I'm more than happy to run commands and send you output as required: the whole thing is giving me the willies. jason -- http://panix.com/~jasonp?BabyPictures From owner-linux-xfs@oss.sgi.com Mon Mar 22 17:11:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Mar 2004 17:11:34 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2N1BSKO032453 for ; Mon, 22 Mar 2004 17:11:29 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2N1BMUo019831 for ; Mon, 22 Mar 2004 19:11:22 -0600 Received: from boing.melbourne.sgi.com (localhost [127.0.0.1]) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2N1BI6b611111; Tue, 23 Mar 2004 12:11:18 +1100 (AEDT) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2N1BG74611179; Tue, 23 Mar 2004 12:11:16 +1100 (AEDT) Date: Tue, 23 Mar 2004 12:11:16 +1100 From: Tim Shimmin To: Mandy Kirkconnell Cc: Jason Parker-Burlingham , Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: xfsrestore: "is a directory: discarding ino" Message-ID: <20040323121115.C584288@boing.melbourne.sgi.com> References: <878yhtpmxi.fsf@freezer.burling> <20040322212635.GA699@frodo> <405F6B77.70308@sgi.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <405F6B77.70308@sgi.com>; from alkirkco@sgi.com on Mon, Mar 22, 2004 at 04:40:55PM -0600 Content-Transfer-Encoding: 8bit X-archive-position: 2540 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3399 Lines: 76 Hi, Another thing that may be helpful is some debugging output for restore. The verbose option of -v5 gives useful stuff. However, on large restores it may produce annoyingly large output. If the output is too large then it may be helpful to turn on debugging at a particular point in the code using mlog_override_level(). For example, to turn on debugging just prior to the "directory post-processing": $ p_rdiff -u content.c --- xfsdump/restore/content.c_1.32 2004-03-23 12:06:43.000000000 +1100 +++ xfsdump/restore/content.c 2004-03-23 12:00:15.000000000 +1100 @@ -2343,6 +2343,7 @@ mlog( MLOG_VERBOSE, _( "directory post-processing\n") ); win_locks_off(); /* we are single threaded here */ +mlog_override_level(5); rv = treepost( path1, path2 ); win_locks_on(); switch ( rv ) { --Tim On Mon, Mar 22, 2004 at 04:40:55PM -0600, Mandy Kirkconnell wrote: > Nathan Scott wrote: > > On Sun, Mar 21, 2004 at 10:42:33PM -0500, Jason Parker-Burlingham wrote: > > > >>I'm running a 2.4.23 kernel from CVS with LVM1 patches applied. I'm > >>trying to move an XFS filesystem from one logical volume to another > >>using xfsrestore 2.2.18 and not having a lot of success: > >> > >> # xfsdump -J - /mnt | xfsrestore -J - /pivot > >> [...] > >> xfsrestore: reading directories > >> xfsdump: dumping non-directory files > >> xfsrestore: 2694 directories and 69903 entries processed > >> xfsrestore: directory post-processing > >> xfsrestore: WARNING: mkdir failed: No such file or directory > >> xfsrestore: WARNING: mkdir failed: No such file or directory > >> xfsrestore: WARNING: mkdir failed: No such file or directory > >> xfsrestore: WARNING: mkdir failed: No such file or directory > >> xfsrestore: WARNING: unable to set non-root extended attribute for : No such file or directory (2) > >> xfsrestore: WARNING: unable to set secure extended attribute for : No such file or directory (2) > >> xfsrestore: restoring non-directory files > >> xfsrestore: WARNING: open of ///gconf.xml.defaults/schemas///UI/ failed: No such file or directory: discarding ino 135 > >> [...] > >> xfsrestore: WARNING: open of /Kodak Pictures// failed: Is a directory: discarding ino 10811 > >> > >>The point at which the errors occur does not appear to be repeatable. > >> > >>If I let the dump/restore run to completion, xfsrestore reports > >>success and the filesystem appears to be complete, but directory > >>permissions are set to 000. > >> > >>Is there some other option I should be passing to xfsrestore? > > > > > > Don't think so, looks like a bug. Almost looks like the filename > > string is null for some reason, somewhere in restore (those mkdir > > errors, etc, above - look like they're trying to print filenames). > > > > Does this ring any bells Mandy? > > No, this is new to me. I agree that it looks like there are a bunch of > null filename strings. Jason, you mentioned that the point of error > doesn't seem to be consistent but it sounds like it's reproducible in > the sense that you've seen this behaviour more than once. Is there > anything unique or special about the data you're restoring? It looks > like the FS may have extended attributes (non-root, secure, or both ??). > I haven't been able to repro this yet so any additional info would be > helpful. > > Mandy > From owner-linux-xfs@oss.sgi.com Mon Mar 22 17:15:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Mar 2004 17:15:53 -0800 (PST) Received: from amber.he.net (amber.he.net [216.218.172.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2N1FnKO000482 for ; Mon, 22 Mar 2004 17:15:49 -0800 Received: from stinkpad ([208.35.40.2] (may be forged)) by amber.he.net (8.8.6p2003-03-31/8.8.2) with ESMTP id RAA27552; Mon, 22 Mar 2004 17:15:56 -0800 Message-Id: <200403230115.RAA27552@amber.he.net> From: "Mike Young" To: "'Nathan Scott'" Cc: Subject: RE: External Journal and ACL Support Date: Mon, 22 Mar 2004 17:16:51 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20040322233621.GG699@frodo> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 thread-index: AcQQZ87G1c4QjPBPRz2TO7rHsGggVwAAL6Iw X-archive-position: 2541 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: myoung@wildernessvoice.com Precedence: bulk X-list: linux-xfs Content-Length: 3132 Lines: 97 Hi Nathan, Here's the info you requested based on my default settings, which do not include the use of the external journal: sh-2.04# xfs_info.sh /hd/vol_mnt0/ meta-data=/hd/vol_mnt0 isize=1024 agcount=35, agsize=1048560 blks data = bsize=4096 blocks=36397056, imaxpct=25 = sunit=16 swidth=32 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768 version=2 = sunit=1 blks realtime =none extsz=65536 blocks=0, rtextents=0 At this point, I should point out that I've just realized that my default inode size is not 1k, but rather 256. I'm also specifying sunit and swidth, and didn't realize that the default inode drops back down to a lower default. I'm going to rerun the tests with 1k then 2k inode size. However, you may still be interested in the performance impact described below. Again, when I say "with acls", the inode size is 256. Also, as far as performance goes, when acls are turned off, and the journal is placed on an external device, the nbench throughput is 60MB/sec at 6 clients. It tapers off to 53MB/sec at 32 clients. However, when I turn acls on, my peak is 40MB/sec at 4 clients and drops to 26MB/sec at 30 clients. If I rerun the last test, but with the internal journal, my peak goes back up to 52MB/sec and the low is 37MB/sec. I'll let you know how things go. -Mike -----Original Message----- From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Nathan Scott Sent: Monday, March 22, 2004 3:36 PM To: Mike Young Cc: 'Chris Wedgwood'; linux-xfs@oss.sgi.com Subject: Re: External Journal and ACL Support On Mon, Mar 22, 2004 at 03:28:05PM -0800, Mike Young wrote: > Hi Chris, > > That's an excellent question. My default is 1k right now. I'm going to > give 2k a try. Can you send your filesystem geometry (xfs_info output)? And any performance numbers you have for each of the different geometries you've tried would be good to see too. The difference moving from the default 256 byte inode to any larger inode size is where the big gains are seen, I wouldn't expect too much improvement going from 1k to 2k. Though it may help a bit for small directories with ACLs... (and small directories in general). cheers. > -----Original Message----- > From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com] On > Behalf Of Chris Wedgwood > Sent: Monday, March 22, 2004 3:17 PM > To: Mike Young > Cc: linux-xfs@oss.sgi.com > Subject: Re: External Journal and ACL Support > > On Mon, Mar 22, 2004 at 02:31:16PM -0800, Mike Young wrote: > > > To set the journaling up for external placement, I'm using "mkfs.xfs > > /dev/md1 -l logdev=/dev/md0,size=10000b". For ACLs, I'm just using > > getfacl to store the acls in a file till I can reapply them to the > > new directories using "setfacl -set-file". > > Do larger inodes help? I wonder is with ACLs you're not becoming > seek-bound on metadata. > > > > --cw > > > > > -- Nathan From owner-linux-xfs@oss.sgi.com Mon Mar 22 23:56:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Mar 2004 23:56:27 -0800 (PST) Received: from hob.acsalaska.net (hob.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2N7u5KO017691 for ; Mon, 22 Mar 2004 23:56:06 -0800 Received: from erbenson.alaska.net (21-pm33.nwc.acsalaska.net [209.112.159.21]) by hob.acsalaska.net (8.12.11/8.12.11) with ESMTP id i2N7trNY024161 for ; Mon, 22 Mar 2004 22:55:55 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 1A33C39E3 for ; Mon, 22 Mar 2004 22:55:51 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 932BE40FF35; Mon, 22 Mar 2004 22:55:51 -0900 (AKST) Date: Mon, 22 Mar 2004 22:55:51 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Recommened XFS settings for a laptop Message-ID: <20040323075551.GK21226@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200403221626.41593.te@macnews.de> Mime-Version: 1.0 Content-type: text/plain Content-Disposition: inline In-Reply-To: <200403221626.41593.te@macnews.de> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.63; spamdefang 1.93 Content-Transfer-Encoding: 8bit X-archive-position: 2542 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 1945 Lines: 45 On Mon, Mar 22, 2004 at 04:26:41PM +0100, Tobias Eichert wrote: > Hello XFS ML, > > I use XFS on an IBM Thinkpad with a 60GB harddisk. My question is: > Are there any recommended settings for using XFS on a laptop? > > Last time I started an OpenGL app in fullscreen mode I experienced a system > freeze (couldn't even switch to a console to kill that process) and so I had > to do a system restart without unmounting my partitions in a friendly > manner. ;) > After everything was up and running again I noticed that KDE had a different > look&feel - for example, colors and font sizes changed to their default > values (which makes me believe that some of the config files got corrupted > and KDE using the default ones). This assumption is stressed by the fact > that, on a previous installation and system freeze I indeed had corrupted kde > config files (using XFS). gnome/kde tend to be bad about holding various config files open and writing to them frequently, so i would recommend using chattr -R +S on your .kde directory and other config directories/files. that should ensure they never get blocks of NUL bytes on bad shutdowns. > Are there any recommeded settings (especially mount and sysctl options) for > XFS (on a laptop)? Note that this system freeze isn't really laptop specific > (why should it be? ;)) but if there are XFS-on-a-laptop users on this list > I'd really appreciate some hints, tipps and tricks for running XFS as stable > as possible. What about journalling / ordered data modes - commit intervalls, > noatime, etc.. ? noatime is popular on laptops to help keep the disk spun down longer. -- Ethan Benson http://www.alaska.net/~erbenson/ -- Attached file included as plaintext by Ecartis -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkBf7YcACgkQJKx7GixEevwwEwCeOppDWX6vsQH7iw++y/He/LSI XAUAnjCcIW8XCE7YEIpmkk4tIuIWnsPa =vLfd -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Tue Mar 23 00:01:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Mar 2004 00:02:08 -0800 (PST) Received: from malik.acsalaska.net (malik.acsalaska.net [209.112.155.41]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2N81uKO018382 for ; Tue, 23 Mar 2004 00:01:56 -0800 Received: from erbenson.alaska.net (21-pm33.nwc.acsalaska.net [209.112.159.21]) by malik.acsalaska.net (8.12.11/8.12.11) with ESMTP id i2N81snB066741 for ; Mon, 22 Mar 2004 23:01:54 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 914E239E3 for ; Mon, 22 Mar 2004 23:01:52 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 421E040FF35; Mon, 22 Mar 2004 23:01:53 -0900 (AKST) Date: Mon, 22 Mar 2004 23:01:53 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: xfsrestore: "is a directory: discarding ino" Message-ID: <20040323080153.GL21226@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <878yhtpmxi.fsf@freezer.burling> <20040322212635.GA699@frodo> <405F6B77.70308@sgi.com> <87vfkwo27k.fsf@freezer.burling> Mime-Version: 1.0 Content-type: text/plain Content-Disposition: inline In-Reply-To: <87vfkwo27k.fsf@freezer.burling> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.63; spamdefang 1.93 Content-Transfer-Encoding: 8bit X-archive-position: 2543 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 744 Lines: 23 On Mon, Mar 22, 2004 at 07:07:43PM -0500, Jason Parker-Burlingham wrote: > helpful. getfattr(1) doesn't reveal anything except for > user.SGI_XFSDUMP_SKIP_FILE on temp directory (yes, it doesn't work; I > know). How can I list root extended attributes? use chattr +d on the directory instead, by default that will be propagated to new files and directories created there, all the directories will still be dumped, but none of the files. -- Ethan Benson http://www.alaska.net/~erbenson/ -- Attached file included as plaintext by Ecartis -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkBf7vEACgkQJKx7GixEevwD3gCeJOYk8XjEj1e+99V36wNtRpKB DK0AnRRFKeXqLSIn381AB7x4+krfvwZW =CSQU -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Tue Mar 23 00:14:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Mar 2004 00:15:30 -0800 (PST) Received: from web41415.mail.yahoo.com (web41415.mail.yahoo.com [66.218.93.81]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2N8EXKO019109 for ; Tue, 23 Mar 2004 00:14:36 -0800 Message-ID: <20040323081428.7924.qmail@web41415.mail.yahoo.com> Received: from [203.199.146.111] by web41415.mail.yahoo.com via HTTP; Tue, 23 Mar 2004 00:14:28 PST Date: Tue, 23 Mar 2004 00:14:28 -0800 (PST) From: ankur mattoo Subject: what the hell is acl_t To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2544 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: coolpal53@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 949 Lines: 38 hi im currently working on stakable file system wrapfs. 1.>Well im writing a kernel code in which im supposed to receive ioctl argument from the user space which is supposed to be of the type acl_t. I mean: <> acl_t the_acl; ioctl(File_Desc,FIST_IOCTL_SET_SEC_DESC,the_acl) now the kernel code doesn't seem to recognize acl_t and reports an error. Im compiling the kernel code with -lacl flag and there is complete acl and xattr support in the kernel.[linux-2.4.23 with ea patch] what can i do bout it. 2.>In the kernel code i wanna set the acls of a file using setxattr.Consider i have a inode object ankinode; what name:value pair should i write corresponding to an acl_t perm; I mean i have the variable perm and i gotta run setxattr. How can i do that??? Any help!!! thanks ankur -BE __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html From owner-linux-xfs@oss.sgi.com Tue Mar 23 01:28:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Mar 2004 01:29:08 -0800 (PST) Received: from hell.org.pl (qmailr@hell.org.pl [212.244.218.42]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2N9SeKO025607 for ; Tue, 23 Mar 2004 01:28:41 -0800 Received: (qmail 15066 invoked by uid 777); 23 Mar 2004 09:28:41 -0000 Date: Tue, 23 Mar 2004 10:28:41 +0100 From: Karol Kozimor To: linux-xfs@oss.sgi.com Subject: Re: Recommened XFS settings for a laptop Message-ID: <20040323092840.GA15593@hell.org.pl> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200403221626.41593.te@macnews.de> <20040323075551.GK21226@plato.local.lan> Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <20040323075551.GK21226@plato.local.lan> User-Agent: Mutt/1.4.2i Content-Transfer-Encoding: 8bit X-archive-position: 2545 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sziwan@hell.org.pl Precedence: bulk X-list: linux-xfs Content-Length: 824 Lines: 19 Thus wrote Ethan Benson: > > Are there any recommeded settings (especially mount and sysctl options) for > > XFS (on a laptop)? Note that this system freeze isn't really laptop specific > > (why should it be? ;)) but if there are XFS-on-a-laptop users on this list > > I'd really appreciate some hints, tipps and tricks for running XFS as stable > > as possible. What about journalling / ordered data modes - commit intervalls, > > noatime, etc.. ? > noatime is popular on laptops to help keep the disk spun down longer. Last time I checked, the XFS-specific sysctls had their maximum values too low to achieve sufficient disk spin-downs, especially with laptop-mode. I remember someone (Steve Lord?) even suggested to up those limits. Could this be done? Best regards, -- Karol 'sziwan' Kozimor sziwan@hell.org.pl From owner-linux-xfs@oss.sgi.com Tue Mar 23 06:49:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Mar 2004 06:50:06 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2NEnrKO008303 for ; Tue, 23 Mar 2004 06:49:53 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2NFp0iQ020346 for ; Tue, 23 Mar 2004 07:51:01 -0800 Received: from sgi.com (syntegra.americas.sgi.com [128.162.232.81]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2NEnlKe35782328; Tue, 23 Mar 2004 08:49:47 -0600 (CST) Message-ID: <40604E71.8080609@sgi.com> Date: Tue, 23 Mar 2004 08:49:21 -0600 From: Mandy Kirkconnell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Jason Parker-Burlingham CC: linux-xfs@oss.sgi.com Subject: Re: xfsrestore: "is a directory: discarding ino" References: <878yhtpmxi.fsf@freezer.burling> <20040322212635.GA699@frodo> <405F6B77.70308@sgi.com> <87vfkwo27k.fsf@freezer.burling> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2546 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alkirkco@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1407 Lines: 36 Jason Parker-Burlingham wrote: > Mandy Kirkconnell writes: > >>I agree that it looks like there are a bunch of null filename >>strings. > > I thought of this, too. > >>Jason, you mentioned that the point of error doesn't seem to be >>consistent but it sounds like it's reproducible in the sense that >>you've seen this behaviour more than once. > > > Happens every time I pipe xfsdump into xfsrestore. Do you mean ONLY when the data is piped? Have you tried dumping to a file then restoring the file (ie. -f /tmp/dumpfile)? The dump file could get quite big depending on the size of your filesystem but it might be a good thing to test. It may even narrow this down to either the dump or the restore. I'm wondering if piping the data is causing the problem to _appear_ in xfsrestore but the problem may actually be in the dump. > I'm more than happy to run commands and send you output as required: > the whole thing is giving me the willies. As Tim suggested, turning on debugging would be helpful. If your filesystem is reasonably small you can use the -v option to increase verbosity to -v3, -v4 or even -v5 but this may be a lot of output. I guess I would start with the -v on the xfsrestore command for now. If it looks like xfsrestore is reading in null strings from stdin then we'll probably want to take a look at the xfsdump debugging as well. Mandy From owner-linux-xfs@oss.sgi.com Tue Mar 23 09:43:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Mar 2004 09:43:45 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2NHhgKO019144 for ; Tue, 23 Mar 2004 09:43:43 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2NJkTjD030935 for ; Tue, 23 Mar 2004 11:46:29 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2NHhbKe35756879 for ; Tue, 23 Mar 2004 11:43:37 -0600 (CST) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i2NHhZXa2230832; Tue, 23 Mar 2004 11:43:36 -0600 (CST) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id i2NHgB8D028009; Tue, 23 Mar 2004 11:42:12 -0600 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id i2NHg94I028007; Tue, 23 Mar 2004 11:42:09 -0600 Date: Tue, 23 Mar 2004 11:42:09 -0600 From: Eric Sandeen Message-Id: <200403231742.i2NHg94I028007@penguin.americas.sgi.com> Subject: PARTIAL TAKE 910631 - X-archive-position: 2547 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 602 Lines: 25 Change fsr routines so that they don't copy data unless the extent count has improved. This should speed things up a bit. Date: Tue Mar 23 09:43:02 PST 2004 Workarea: penguin.americas.sgi.com:/src/eric/xfs-cmds Inspected by: cwf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:168942a xfsdump/VERSION - 1.59 - Bump version xfsdump/doc/CHANGES - 1.66 - Doc fsr changes xfsdump/fsr/xfs_fsr.c - 1.16 - Change fsr routines so that they don't copy data unless the extent count has improved. This should speed things up a bit. From owner-linux-xfs@oss.sgi.com Tue Mar 23 09:56:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Mar 2004 09:56:41 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2NHuXKO019804 for ; Tue, 23 Mar 2004 09:56:33 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2NIvfiQ031713 for ; Tue, 23 Mar 2004 10:57:41 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2NHuRKe35745985 for ; Tue, 23 Mar 2004 11:56:27 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i2NHuREq3064379 for ; Tue, 23 Mar 2004 11:56:27 -0600 (CST) Subject: Re: PARTIAL TAKE 910631 - From: Eric Sandeen To: linux-xfs@oss.sgi.com In-Reply-To: <200403231742.i2NHg94I028007@penguin.americas.sgi.com> References: <200403231742.i2NHg94I028007@penguin.americas.sgi.com> Content-type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1080064586.28106.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 23 Mar 2004 11:56:27 -0600 Content-Transfer-Encoding: 8bit X-archive-position: 2548 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 943 Lines: 31 I should mention that this was submitted by Chris Wedgwood, and was also similarly suggested by Utz Lehmann. Thanks guys! On Tue, 2004-03-23 at 11:42, Eric Sandeen wrote: > Change fsr routines so that they don't copy data unless > the extent count has improved. This should speed things > up a bit. > > Date: Tue Mar 23 09:43:02 PST 2004 > Workarea: penguin.americas.sgi.com:/src/eric/xfs-cmds > Inspected by: cwf > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/xfs-cmds > > > Modid: xfs-cmds:slinx:168942a > xfsdump/VERSION - 1.59 > - Bump version > > xfsdump/doc/CHANGES - 1.66 > - Doc fsr changes > > xfsdump/fsr/xfs_fsr.c - 1.16 > - Change fsr routines so that they don't copy data unless > the extent count has improved. This should speed things > up a bit. -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Mar 23 14:52:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Mar 2004 14:53:02 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2NMqwKO002565 for ; Tue, 23 Mar 2004 14:52:58 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2NNs6iQ016998 for ; Tue, 23 Mar 2004 15:54:07 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA25397; Wed, 24 Mar 2004 09:52:49 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2NMqjFx623981; Wed, 24 Mar 2004 09:52:46 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i2NMq6m9000955; Wed, 24 Mar 2004 09:52:07 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i2NMq6ja000953; Wed, 24 Mar 2004 09:52:06 +1100 Date: Wed, 24 Mar 2004 09:52:06 +1100 From: Nathan Scott To: Mike Young Cc: linux-xfs@oss.sgi.com Subject: Re: External Journal and ACL Support Message-ID: <20040323225206.GC733@frodo> References: <20040322233621.GG699@frodo> <200403230115.RAA27552@amber.he.net> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403230115.RAA27552@amber.he.net> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2549 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1138 Lines: 35 On Mon, Mar 22, 2004 at 05:16:51PM -0800, Mike Young wrote: > Hi Nathan, > > ... > At this point, I should point out that I've just realized that my default > inode size is not 1k, but rather 256. I'm also specifying sunit and swidth, :) I thought that might be the case, the difference in performance was inexplicable to me otherwise. > you may still be interested in the performance impact described below. > Again, when I say "with acls", the inode size is 256. Yep. > Also, as far as performance goes, when acls are turned off, and the journal > is placed on an external device, the nbench throughput is 60MB/sec at 6 > clients. It tapers off to 53MB/sec at 32 clients. However, when I turn > acls on, my peak is 40MB/sec at 4 clients and drops to 26MB/sec at 30 > clients. If I rerun the last test, but with the internal journal, my peak > goes back up to 52MB/sec and the low is 37MB/sec. OK, I can understand that with non-inline attrs (there's more I/O involved, and the additional read can only happen after the inode has first been read) > I'll let you know how things go. Great, thanks Mike. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Mar 23 15:03:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Mar 2004 15:03:36 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2NN3VKO003555 for ; Tue, 23 Mar 2004 15:03:31 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2O16IW0021473 for ; Tue, 23 Mar 2004 17:06:18 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA25545; Wed, 24 Mar 2004 10:03:21 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2NN3GFx215414; Wed, 24 Mar 2004 10:03:17 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i2NN2bm9000993; Wed, 24 Mar 2004 10:02:38 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i2NN2ZNi000991; Wed, 24 Mar 2004 10:02:35 +1100 Date: Wed, 24 Mar 2004 10:02:35 +1100 From: Nathan Scott To: ankur mattoo , acl-devel@bestbits.at Subject: Re: what the hell is acl_t Message-ID: <20040323230235.GD733@frodo> References: <20040323081428.7924.qmail@web41415.mail.yahoo.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040323081428.7924.qmail@web41415.mail.yahoo.com> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2550 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1582 Lines: 54 On Tue, Mar 23, 2004 at 12:14:28AM -0800, ankur mattoo wrote: > hi > im currently working on stakable file system wrapfs. Since these are ACL questions, not XFS questions, I've sent this reply to a more appropriate forum. > 1.>Well im writing a kernel code in which im supposed > to receive ioctl argument from the user space which is > supposed to be of the type acl_t. I mean: You should probably step back a stage, and explain why the xattr interfaces are unsuitable and ioctl is chosen, etc, so that people can see where you're coming from. > <> > > acl_t the_acl; > ioctl(File_Desc,FIST_IOCTL_SET_SEC_DESC,the_acl) > > now the kernel code doesn't seem to recognize acl_t > and reports an error. Im compiling the kernel code > with -lacl > flag and there is complete acl and xattr support in > the kernel.[linux-2.4.23 with ea patch] > what can i do bout it. > > 2.>In the kernel code i wanna set the acls of a file > using setxattr.Consider i have a inode object > ankinode; > > what name:value pair should i write corresponding to > an acl_t perm; > > I mean i have the variable perm and i gotta run > setxattr. How can i do that??? > Any help!!! > thanks > ankur The user/kernel interface (correct me, Andreas, its been awhile ;) uses posix_acl_xattr_header/posix_acl_xattr_entry structs for all communication; the acl_t is for libacl/application communication only, and doesn't cross the syscall boundary. I guess you could look closely at where libacl talks to the kernel to get a better idea of how it all fits together. HTH. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Mar 23 18:52:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Mar 2004 18:52:57 -0800 (PST) Received: from vcgwp1.bit-drive.ne.jp (vcgwp1.bit-drive.ne.jp [211.9.32.211]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2O2qpKO019467 for ; Tue, 23 Mar 2004 18:52:51 -0800 Received: (qmail 296 invoked from network); 24 Mar 2004 11:52:49 +0900 Received: from unknown (HELO dns01.miraclelinux.com) (219.118.163.66) by vcgwp1.bit-drive.ne.jp with SMTP; 24 Mar 2004 11:52:49 +0900 Received: from miraclelinux.com (dhcp-0139.miraclelinux.com [10.1.0.139]) by dns01.miraclelinux.com (8.9.3+3.2W/3.7W/03090111) with ESMTP id LAA22127 for ; Wed, 24 Mar 2004 11:52:49 +0900 Message-ID: <4060F7FC.8090602@miraclelinux.com> Date: Wed, 24 Mar 2004 11:52:44 +0900 From: "IKARASHI, Seiichi" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: synchronization of XFS Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2551 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ikarashi@miraclelinux.com Precedence: bulk X-list: linux-xfs Content-Length: 297 Lines: 13 Hello, How do you guys synchronize a XFS partition? I'm stacking 'cause XFS partitions seem to take longer time than other filesystems like ext3 or reiserfs to really write down to HDD. Repeating sync() does not take effect. Is there any specific command or operation to sync XFS? Thanks, Sei From owner-linux-xfs@oss.sgi.com Tue Mar 23 21:30:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Mar 2004 21:30:51 -0800 (PST) Received: from snow.csi.cam.ac.uk (snow.csi.cam.ac.uk [131.111.8.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2O5UiKO006294 for ; Tue, 23 Mar 2004 21:30:45 -0800 Received: from tanzanite.trinhall.cam.ac.uk ([131.111.228.184] helo=tanzanite) by snow.csi.cam.ac.uk with esmtp (Exim 4.20) id 1B60yF-0006E3-B7; Wed, 24 Mar 2004 05:30:31 +0000 From: Jeff Snyder To: sandeen@penguin.americas.sgi.com Subject: xfs_repair dies with a fatal error Date: Wed, 24 Mar 2004 05:30:25 +0000 User-Agent: KMail/1.6 Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Disposition: inline Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Message-Id: <200403240530.25783.jeff@caffeinated.me.uk> X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-archive-position: 2552 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jeff@caffeinated.me.uk Precedence: bulk X-list: linux-xfs Content-Length: 2639 Lines: 60 Hi, I've been having some problems getting xfs_repair to work on one of my xfs filesystems.. after talking to Eric Sandeen on #xfs irc for a bit he suggested that I post my findings to the list, so here goes (: the case: http://oss.sgi.com/archives/linux-xfs/2002-08/msg00243.html is similar to mine, the error message and the xfs_db stuff. I'm getting the error "fatal error -- can't read block 0 for directory inode xxxxxxxx" when i try to run xfs_repair. The filesystem is on an evms volume, which is part of an LVM which is on a raid1 array. full output of xfs_repair is at: http://caffeinated.me.uk/~jeff/xfs_repair_script there were no hardware errors logged, and the output is fully repeatable. I've taken gdb to xfs_repair, and the output is coming from phase6.c:2723 - if (libxfs_da_read_bufr(NULL, ip, da_bno, -1, &bp, XFS_DATA_FORK)) { do_error(_("can't read block %u for directory inode " "%llu\n"), digging deeper, libxfs_da_read_bufr is a wrapper around xfs_da_do_buf, and the error code is getting set in xfs_da_do_buf at xfs_da_btree.c:2082 - error = mappedbno == -2 ? 0 : XFS_ERROR(EFSCORRUPTED); if (unlikely(error == EFSCORRUPTED)) { if (xfs_error_level >= XFS_ERRLEVEL_LOW) { .. error reporting code, didnt execute .. } } goto exit0; so xfs_da_do_buf returns EFSCORRUPTED, hence do_error gets called. after forcing the error reporting code from the above snippet to execute, i got the extra output: "xfs_da_do_buf: bno 0" "dir: inode 8713174". Well, I hope thats useful to someone.. if it's fixable & my filesystem can be repaired, i'd love to know about it asap, so please cc me on all replies as I'm not on the list (-: Cheers, Jeff some background info on how this happened, for the bored: I set up a 1-way raid1 mirror on evms, on a new hdd, and put a lvm on the raid1. then made various volumes in the lvm, for my entire system (/, /user, /home, ....). I made xfs filesystems on all of these, and moved my files over. I then rebooted to a livecd, and added the 2nd partition to the 1-way raid1 mirror with evms(n) to make it 2-way, the raid sync'd, and I rebooted, got lots of kernel oops's looking xfs-related as soon as / was mounted, I didnt even see init start. Went back to the livecd, the raid wanted to sync again, i let it, then xfs_check'd all the partitions - at least 4 of them were siginifigantly damaged, but all were repairable apart from /usr. From owner-linux-xfs@oss.sgi.com Tue Mar 23 23:11:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Mar 2004 23:11:35 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2O7BNKO009969 for ; Tue, 23 Mar 2004 23:11:23 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2O9EC1a015444 for ; Wed, 24 Mar 2004 01:14:13 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA02148; Wed, 24 Mar 2004 18:11:08 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2O7B1Fx633564; Wed, 24 Mar 2004 18:11:03 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i2O7AKm9002319; Wed, 24 Mar 2004 18:10:21 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i2O7ABgs002317; Wed, 24 Mar 2004 18:10:11 +1100 Date: Wed, 24 Mar 2004 18:10:11 +1100 From: Nathan Scott To: Jeff Snyder Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair dies with a fatal error Message-ID: <20040324071011.GD1383@frodo> References: <200403240530.25783.jeff@caffeinated.me.uk> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403240530.25783.jeff@caffeinated.me.uk> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2553 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 532 Lines: 23 On Wed, Mar 24, 2004 at 05:30:25AM +0000, Jeff Snyder wrote: > Hi, > ... > I'm getting the error "fatal error -- can't read block 0 for directory inode > xxxxxxxx" when i try to run xfs_repair. The filesystem is on an evms volume, hi Jeff, Grab the xfs_repair from cvs on oss.sgi.com, it has a fix for this issue. From xfsprogs/doc/CHANGES... xfsprogs-2.6.7 (19 March 2003) ... - Fix xfs_repair handling of version 2 directories with a hole at the start. So 2.6.7 or later should do it. :) cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Mar 23 23:32:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Mar 2004 23:32:25 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2O7WBKO011031 for ; Tue, 23 Mar 2004 23:32:13 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2O7W3f0026757 for ; Wed, 24 Mar 2004 01:32:04 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2O7W0AL22835160 for ; Wed, 24 Mar 2004 18:32:01 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2O7VxVc23911542 for linux-xfs@oss.sgi.com; Wed, 24 Mar 2004 18:31:59 +1100 (EST) Date: Wed, 24 Mar 2004 18:31:59 +1100 (EST) From: Nathan Scott Message-Id: <200403240731.i2O7VxVc23911542@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 908809 - pagebuf X-archive-position: 2554 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 446 Lines: 15 Fix a very hard-to-hit, small-block-size only corruption from a recent change (for 2.6 cvs users only, no other trees were affected). Date: Tue Mar 23 23:30:46 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-xfs-linux Inspected by: hch@lst.de The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:168987a linux-2.6/xfs_buf.c - 1.159 linux-2.4/xfs_buf.c - 1.180 From owner-linux-xfs@oss.sgi.com Wed Mar 24 00:28:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 00:29:09 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2O8SsKO016051 for ; Wed, 24 Mar 2004 00:28:54 -0800 Received: from fort.demeern.sgi.com (fort.demeern.sgi.com [144.253.208.2]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2OAVi5e024291 for ; Wed, 24 Mar 2004 02:31:45 -0800 Received: from capelle.demeern.sgi.com (capelle.demeern.sgi.com [144.253.208.25]) by fort.demeern.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF.hoststrip-1.1) via ESMTP id JAA05753; Wed, 24 Mar 2004 09:28:20 +0100 (MET) Received: from capelle.demeern.sgi.com (localhost [127.0.0.1]) by capelle.demeern.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2O8RrlE094010; Wed, 24 Mar 2004 09:28:07 +0100 (MET) Received: (from olaf@localhost) by capelle.demeern.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2O8R2R8093997; Wed, 24 Mar 2004 09:27:02 +0100 (MET) X-Authentication-Warning: capelle.demeern.sgi.com: olaf set sender to olaf@sgi.com using -f To: Jeff Snyder Cc: sandeen@penguin.americas.sgi.com, linux-xfs@oss.sgi.com Subject: Re: xfs_repair dies with a fatal error References: <200403240530.25783.jeff@caffeinated.me.uk> Content-type: text/plain; charset=US-ASCII From: Olaf Weber Date: 24 Mar 2004 09:27:01 +0100 In-Reply-To: <200403240530.25783.jeff@caffeinated.me.uk> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-archive-position: 2555 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1806 Lines: 43 Jeff Snyder writes: > Hi, > I've been having some problems getting xfs_repair to work on one of my xfs > filesystems.. after talking to Eric Sandeen on #xfs irc for a bit he > suggested that I post my findings to the list, so here goes (: > the case: http://oss.sgi.com/archives/linux-xfs/2002-08/msg00243.html is > similar to mine, the error message and the xfs_db stuff. > I'm getting the error "fatal error -- can't read block 0 for directory inode > xxxxxxxx" when i try to run xfs_repair. The filesystem is on an evms volume, > which is part of an LVM which is on a raid1 array. full output of xfs_repair > is at: > http://caffeinated.me.uk/~jeff/xfs_repair_script We have open bugs for this, but unfortunately at present no clean solution. A quick and dirty solution is to use xfs_db to junk the inode, so xfs_repair can finish. Files in the directory will end up in lost+found, named after their inode numbers. To make it easier to get those files back to their original names, you may want to use xfs_db first to get as much of the filename->inode mapping in the directory as possible. A small awk or perl script can then help restoring the original names. To destroy the directory, you'd use the -x option of xfs_db to enable writes, and overwrite the first couple of fields, in particular core.magic, core.mode, core.version, and core.format. E.g, xfs_db -x /dev/.... xfs_db: inode 8713174 xfs_db: write core.magic 0 xfs_db: write core.mode 0 xfs_db: write core.version 0 xfs_db: write core.format 0 -- Olaf Weber SGI Phone: +31(0)30-6696777 Veldzigt 2a Fax: +31(0)30-6696899 Tech Support Engineer 3454 PW de Meern Vnet: 955-7151 Global Product Support The Netherlands Email: olaf@sgi.com From owner-linux-xfs@oss.sgi.com Wed Mar 24 02:33:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 02:33:31 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2OAXGKO020022 for ; Wed, 24 Mar 2004 02:33:17 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2OAXGtP020021 for linux-xfs@oss.sgi.com; Wed, 24 Mar 2004 02:33:16 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2OAXFKQ020007 for ; Wed, 24 Mar 2004 02:33:15 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2OAJBH5019473; Wed, 24 Mar 2004 02:19:11 -0800 Date: Wed, 24 Mar 2004 02:19:11 -0800 Message-Id: <200403241019.i2OAJBH5019473@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 320] New: xfsinvutil -i crash with segfault X-Bugzilla-Reason: AssignedTo X-archive-position: 2556 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 5920 Lines: 122 http://oss.sgi.com/bugzilla/show_bug.cgi?id=320 Summary: xfsinvutil -i crash with segfault Product: Linux XFS Version: unspecified Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: High Component: xfsdump AssignedTo: xfs-master@oss.sgi.com ReportedBy: Nicolas.Kowalski@imag.fr The server is running Debian GNU/Linux 3.0, kernel 2.4.25 from the upstream. xfsdump (2.2.18) is compiled from the xfs-cmds CVS. "xfsdump -I" runs fine. "xfsinvutil -C" runs fine. "xfsinvutil -i" crashes with a segfault. Here is the output from strace: execve("/usr/sbin/xfsinvutil", ["xfsinvutil", "-i"], [/* 20 vars */]) = 0 uname({sys="Linux", node="gaspard", ...}) = 0 brk(0) = 0x8052bac open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=10278, ...}) = 0 old_mmap(NULL, 10278, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000 close(3) = 0 open("/lib/libuuid.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\v\0"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0644, st_size=8712, ...}) = 0 old_mmap(NULL, 11844, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40017000 mprotect(0x40019000, 3652, PROT_NONE) = 0 old_mmap(0x40019000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x40019000 close(3) = 0 open("/lib/libncurses.so.5", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\337\0"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0644, st_size=248132, ...}) = 0 old_mmap(NULL, 253056, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001a000 mprotect(0x4004f000, 35968, PROT_NONE) = 0 old_mmap(0x4004f000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x34000) = 0x4004f000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\30\222"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=1153784, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40058000 old_mmap(NULL, 1166560, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40059000 mprotect(0x4016c000, 40160, PROT_NONE) = 0 old_mmap(0x4016c000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x113000) = 0x4016c000 old_mmap(0x40172000, 15584, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40172000 close(3) = 0 munmap(0x40014000, 10278) = 0 stat64("/var/lib/xfsdump", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 stat64("/var/xfsdump", 0xbffffbcc) = -1 ENOENT (No such file or directory) brk(0) = 0x8052bac brk(0x8052be4) = 0x8052be4 brk(0x8053000) = 0x8053000 open("/var/lib/xfsdump/inventory/fstab", O_RDWR|O_LARGEFILE) = 3 flock(3, LOCK_EX) = 0 read(3, "\1\0\0\0\5\0\0\0\377\377\377\377\0\0\0\0\0\0\0\0\0\0\0"..., 32) = 32 _llseek(3, 0, [0], SEEK_SET) = 0 mmap2(NULL, 2752, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x40014000 open("/var/lib/xfsdump/inventory/c184a2dc-6b9b-4d01-8181-c6fd34daa176.InvIndex", O_RDWR|O_LARGEFILE) = 4 flock(4, LOCK_EX) = 0 read(4, "\1\0\0\0\1\0\0\0\377\377\377\3771\3\0\0x6\1@\377\377\377"..., 32) = 32 _llseek(4, 0, [0], SEEK_SET) = 0 mmap2(NULL, 312, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0x40015000 brk(0x8054000) = 0x8054000 open("/var/lib/xfsdump/inventory/6514a9bc-4180-40d2-9f94-59c2d590b3b7.StObj", O_RDWR|O_LARGEFILE) = 5 flock(5, LOCK_EX) = 0 read(5, "\1\0\0\0\1\0\0\0\5\0\0\0\320\23\0\0\0\0\0\0A\200@\322\237"..., 32) = 32 _llseek(5, 0, [0], SEEK_SET) = 0 fstat64(5, {st_mode=S_IFREG|0644, st_size=5072, ...}) = 0 _llseek(5, 0, [0], SEEK_SET) = 0 mmap2(NULL, 5072, PROT_READ|PROT_WRITE, MAP_SHARED, 5, 0) = 0x40176000 open("/var/lib/xfsdump/inventory/1bb54683-d619-4bbc-ba16-be7e144229e1.InvIndex", O_RDWR|O_LARGEFILE) = 6 flock(6, LOCK_EX) = 0 read(6, "\1\0\0\0\1\0\0\0\377\377\377\3771\3\0\0x6\1@\377\377\377"..., 32) = 32 _llseek(6, 0, [0], SEEK_SET) = 0 mmap2(NULL, 312, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0) = 0x40016000 open("/var/lib/xfsdump/inventory/4197c50d-45a6-45de-9992-5a35c8c45d96.StObj", O_RDWR|O_LARGEFILE) = 7 flock(7, LOCK_EX) = 0 read(7, "\1\0\0\0\2\0\0\0\5\0\0\0x\26\0\0\0\0\0\0E\246E\336\231"..., 32) = 32 _llseek(7, 0, [0], SEEK_SET) = 0 fstat64(7, {st_mode=S_IFREG|0644, st_size=5752, ...}) = 0 _llseek(7, 0, [0], SEEK_SET) = 0 mmap2(NULL, 5752, PROT_READ|PROT_WRITE, MAP_SHARED, 7, 0) = 0x40178000 open("/var/lib/xfsdump/inventory/2daca37d-1c0a-4958-984b-d63f735bdef0.InvIndex", O_RDWR|O_LARGEFILE) = 8 flock(8, LOCK_EX) = 0 read(8, "\1\0\0\0\1\0\0\0\377\377\377\3771\3\0\0x6\1@\377\377\377"..., 32) = 32 _llseek(8, 0, [0], SEEK_SET) = 0 mmap2(NULL, 312, PROT_READ|PROT_WRITE, MAP_SHARED, 8, 0) = 0x4017a000 open("/var/lib/xfsdump/inventory/07a89215-d9d3-4023-96a1-e0775170cf30.StObj", O_RDWR|O_LARGEFILE) = 9 flock(9, LOCK_EX) = 0 read(9, "\1\0\0\0\2\0\0\0\5\0\0\0\270\23\0\0\0\0\0\0\331\323@#\226"..., 32) = 32 _llseek(9, 0, [0], SEEK_SET) = 0 fstat64(9, {st_mode=S_IFREG|0644, st_size=5048, ...}) = 0 _llseek(9, 0, [0], SEEK_SET) = 0 mmap2(NULL, 5048, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0) = 0x4017b000 --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 24 10:03:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 10:03:29 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2OI3HKO013582 for ; Wed, 24 Mar 2004 10:03:18 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2OJ4WiQ019881 for ; Wed, 24 Mar 2004 11:04:32 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA09709; Thu, 25 Mar 2004 05:03:07 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2OI32Fx648754; Thu, 25 Mar 2004 05:03:02 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2OI30FN555793; Thu, 25 Mar 2004 05:03:00 +1100 (EST) Date: Thu, 25 Mar 2004 05:02:59 +1100 From: Nathan Scott To: Jeff Snyder Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair dies with a fatal error Message-ID: <20040325050259.A587733@wobbly.melbourne.sgi.com> References: <200403240530.25783.jeff@caffeinated.me.uk> <20040324071011.GD1383@frodo> <200403241442.45549.jeff@caffeinated.me.uk> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200403241442.45549.jeff@caffeinated.me.uk>; from jeff@caffeinated.me.uk on Wed, Mar 24, 2004 at 02:42:45PM +0000 Content-Transfer-Encoding: 8bit X-archive-position: 2557 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 860 Lines: 26 On Wed, Mar 24, 2004 at 02:42:45PM +0000, Jeff Snyder wrote: > > OK, done that (with cvs HEAD), and now xfs_repair finishes (:. Good stuff. > However, after running xfs_repair, the filesystem does not appear to be fully > fixed as i still get output from xfs_repair. > > Here's what i get now: http://demantoid.ath.cx/~jeff/xfs_repair_cvs_script > > and I get exactly the same output if i run it again. The first time I ran cvs > xfs_repair, I think it gave some other messages aswell, but i'm afraid I > wasn't recording those.. You will continue to see these disconnected inodes until you move them out of lost+found... that is how xfs_repair works - it removes lost+found early on each time, so anything that was disconnected previously will remain disconnected until some manual intervention to cleanup those inodes is done. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Mar 24 11:33:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 11:33:43 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2OJXJKO021809 for ; Wed, 24 Mar 2004 11:33:19 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2OJXJsA021807 for linux-xfs@oss.sgi.com; Wed, 24 Mar 2004 11:33:19 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2OJXHKQ021789 for ; Wed, 24 Mar 2004 11:33:17 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2OIaxLD020184; Wed, 24 Mar 2004 10:36:59 -0800 Date: Wed, 24 Mar 2004 10:36:59 -0800 Message-Id: <200403241836.i2OIaxLD020184@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 320] xfsinvutil -i crash with segfault X-Bugzilla-Reason: AssignedTo X-archive-position: 2558 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 461 Lines: 18 http://oss.sgi.com/bugzilla/show_bug.cgi?id=320 ------- Additional Comments From nathans@sgi.com 2004-24-03 10:36 PDT ------- Could you provide a gdb backtrace please? (either run the command inside gdb till it dumps core, then "bt", else run 'gdb xfs_invutil core' and do the "bt" - provided you have a core file that is). thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 24 11:40:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 11:40:41 -0800 (PST) Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2OJebKO022462 for ; Wed, 24 Mar 2004 11:40:38 -0800 Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id i2OJauxm010338 for ; Wed, 24 Mar 2004 14:36:56 -0500 (EST) Received: from ms8.netsolmail.com (localhost.netsolmail.com [127.0.0.1]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AUJ97310; Wed, 24 Mar 2004 14:40:35 -0500 (EST) From: Message-Id: <200403241940.AUJ97310@ms8.netsolmail.com> Received: from 65.104.102.243 by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with HTTP/1.1; Wed, 24 Mar 2004 14:40:35 -0500 Date: Wed, 24 Mar 2004 14:40:35 -0500 Subject: Opteron based kernal To: linux-xfs@oss.sgi.com X-Mailer: Webmail Mirapoint Direct 3.2.2-GA MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2559 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian@krusic.com Precedence: bulk X-list: linux-xfs Content-Length: 155 Lines: 9 Hi, Is there an Opteron based kernal project in the works? Are there any advantages using the Athlon kernal over the i686 kernal on the Opteron? Bri- From owner-linux-xfs@oss.sgi.com Wed Mar 24 12:06:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 12:06:23 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2OK6KKO024156 for ; Wed, 24 Mar 2004 12:06:20 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2OM9GE7028126 for ; Wed, 24 Mar 2004 14:09:16 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2OK6EKe35833186; Wed, 24 Mar 2004 14:06:15 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1B6Edh-0006fo-00; Wed, 24 Mar 2004 14:06:13 -0600 Date: Wed, 24 Mar 2004 14:06:13 -0600 From: Nathan Straz To: brian@krusic.com Cc: linux-xfs@oss.sgi.com Subject: Re: Opteron based kernal Message-ID: <20040324200613.GG17673@sgi.com> Mail-Followup-To: brian@krusic.com, linux-xfs@oss.sgi.com References: <200403241940.AUJ97310@ms8.netsolmail.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403241940.AUJ97310@ms8.netsolmail.com> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2560 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 454 Lines: 11 On Wed, Mar 24, 2004 at 02:40:35PM -0500, brian@krusic.com wrote: > Is there an Opteron based kernal project in the works? It's called the x86_64 port. Do some googling and you should be able to find their web site or list archives. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Wed Mar 24 12:33:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 12:33:21 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2OKXIKO028317 for ; Wed, 24 Mar 2004 12:33:18 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2OKXIpf028316 for linux-xfs@oss.sgi.com; Wed, 24 Mar 2004 12:33:18 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2OKXHKQ028302 for ; Wed, 24 Mar 2004 12:33:17 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2OJmX7U023036; Wed, 24 Mar 2004 11:48:33 -0800 Date: Wed, 24 Mar 2004 11:48:33 -0800 Message-Id: <200403241948.i2OJmX7U023036@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 320] xfsinvutil -i crash with segfault X-Bugzilla-Reason: AssignedTo X-archive-position: 2561 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2530 Lines: 55 http://oss.sgi.com/bugzilla/show_bug.cgi?id=320 ------- Additional Comments From Nicolas.Kowalski@imag.fr 2004-24-03 11:48 PDT ------- Here is the gdb backtrace: gaspard:~# xfsinvutil -i Segmentation fault (core dumped) gaspard:~# gdb /usr/sbin/xfsinvutil core GNU gdb 2002-04-01-cvs Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"... Core was generated by `xfsinvutil -i'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libuuid.so.1...done. Loaded symbols for /lib/libuuid.so.1 Reading symbols from /lib/libncurses.so.5...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x400c79ef in malloc () from /lib/libc.so.6 (gdb) bt #0 0x400c79ef in malloc () from /lib/libc.so.6 #1 0x400c7074 in malloc () from /lib/libc.so.6 #2 0x0804e874 in node_create (hidden=1, expanded=0, level=4, deleted=0, file_idx=1, text=0x8054fb8 ' ' , "media file: dlt4000", ops=0x8053320, parent=0x8054f60, children=0x0, nbr_children=0, data_idx=5) at list.c:68 #3 0x0804fdbf in generate_stobj_menu (startnode=0x8054b90, level=2, StObjFileName=0x8054bf8 "/var/lib/xfsdump/inventory/4197c50d-45a6-45de-9992-5a35c8c45d96.StObj") at stobj.c:505 #4 0x0804e322 in generate_invidx_menu (inv_path=0x8053640 "/var/lib/xfsdump/inventory", startnode=0x80541e0, level=1, idxFileName=0x8053f38 "/var/lib/xfsdump/inventory/1bb54683-d619-4bbc-ba16-be7e144229e1.InvIndex") at invidx.c:973 #5 0x0804c1f5 in generate_fstab_menu (inv_path=0x8053640 "/var/lib/xfsdump/inventory", startnode=0x0, level=0, fstabname=0x8053d18 "/var/lib/xfsdump/inventory/fstab") at fstab.c:283 #6 0x0804b9e3 in generate_menu (inv_path=0x8053640 "/var/lib/xfsdump/inventory") at cmenu.c:532 #7 0x0804bb1e in invutil_interactive (inv_path=0x8053640 "/var/lib/xfsdump/inventory", mountpt=0x0, uuidp=0x0, timeSecs=0) at cmenu.c:587 #8 0x08049b5d in main (argc=2, argv=0xbffffd84) at invutil.c:216 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Mar 24 13:47:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 13:47:51 -0800 (PST) Received: from mail2.catalyst.net.nz (godel.catalyst.net.nz [202.49.159.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2OLliKO030763 for ; Wed, 24 Mar 2004 13:47:45 -0800 Received: from leibniz.catalyst.net.nz ([202.49.159.7] helo=shankara.wgtn.cat-it.co.nz) by mail2.catalyst.net.nz with esmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.35 #1 (Debian)) id 1B6GDn-00072V-02 for ; Thu, 25 Mar 2004 09:47:35 +1200 From: Steve Wray Reply-To: stevew@catalyst.net.nz To: linux-xfs@oss.sgi.com Subject: trying to diagnose cause of xfs filesystem corruption Date: Thu, 25 Mar 2004 09:47:34 +1200 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200403250947.34759.stevew@catalyst.net.nz> X-System-Filter-Id: mail2.catalyst.net.nz 1B6GDn-00072V-02 X-Virus-Scanned-By: Amavis with CLAM Anti Virus on mail2.catalyst.net.nz X-archive-position: 2562 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stevew@catalyst.net.nz Precedence: bulk X-list: linux-xfs Content-Length: 2412 Lines: 41 We have a machine with; SATA, software raid, LVM2 and XFS filesystems. LVM2 is appropriately configured to work on software raid. We see corruption on XFS filesystems on real partitions on normal IDE drives (not SATA and no software RAID or LVM) as well as on LVM volumes on SATA drives. Corruption occurs during normal use, there have been no power or kernel panic problems. The kernel is 2.6.4 We are seeing problems with the XFS filesystems like this for example; Mar 21 07:00:05 plato kernel: Filesystem "dm-0": corrupt dinode 21214761, extent total = 1025, nblocks = 2. Unmount and run xfs_repair. Mar 21 07:00:05 plato kernel: 0x0: 49 4e 81 b4 01 02 00 01 00 00 04 10 00 00 00 64 Mar 21 07:00:05 plato kernel: Filesystem "dm-0": XFS internal error xfs_iformat(1) at line 475 of file fs/xfs/xfs_inode.c. Caller 0xc0240\ c0a Mar 21 07:00:05 plato kernel: Call Trace: Mar 21 07:00:05 plato kernel: [xfs_error_report+58/60] xfs_error_report+0x3a/0x3c Mar 21 07:00:05 plato kernel: [xfs_corruption_error+59/72] xfs_corruption_error+0x3b/0x48 Mar 21 07:00:05 plato kernel: [xfs_iread+302/568] xfs_iread+0x12e/0x238 Mar 21 07:00:05 plato kernel: [xfs_iformat+486/1368] xfs_iformat+0x1e6/0x558 Mar 21 07:00:05 plato kernel: [xfs_iread+302/568] xfs_iread+0x12e/0x238 Mar 21 07:00:05 plato kernel: [xfs_iread+302/568] xfs_iread+0x12e/0x238 Mar 21 07:00:05 plato kernel: [xfs_iget_core+541/1272] xfs_iget_core+0x21d/0x4f8 Mar 21 07:00:05 plato kernel: [xfs_iget+140/348] xfs_iget+0x8c/0x15c Mar 21 07:00:05 plato kernel: [xfs_dir_lookup_int+99/200] xfs_dir_lookup_int+0x63/0xc8 Mar 21 07:00:05 plato kernel: [xfs_lookup+62/104] xfs_lookup+0x3e/0x68 Mar 21 07:00:05 plato kernel: [linvfs_lookup+63/124] linvfs_lookup+0x3f/0x7c Mar 21 07:00:05 plato kernel: [real_lookup+89/208] real_lookup+0x59/0xd0 Mar 21 07:00:05 plato kernel: [do_lookup+69/128] do_lookup+0x45/0x80 Mar 21 07:00:05 plato kernel: [link_path_walk+1419/2148] link_path_walk+0x58b/0x864 Mar 21 07:00:05 plato kernel: [path_lookup+341/348] path_lookup+0x155/0x15c Mar 21 07:00:05 plato kernel: [__user_walk+40/64] __user_walk+0x28/0x40 Mar 21 07:00:05 plato kernel: [vfs_lstat+22/68] vfs_lstat+0x16/0x44 Mar 21 07:00:05 plato kernel: [sys_lstat64+19/48] sys_lstat64+0x13/0x30 Mar 21 07:00:05 plato kernel: [sys_setfsuid+111/120] sys_setfsuid+0x6f/0x78 Mar 21 07:00:05 plato kernel: [syscall_call+7/11] syscall_call+0x7/0xb From owner-linux-xfs@oss.sgi.com Wed Mar 24 15:24:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 15:24:24 -0800 (PST) Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2ONOKKO004042 for ; Wed, 24 Mar 2004 15:24:20 -0800 Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id i2ONKcxo029881 for ; Wed, 24 Mar 2004 18:20:39 -0500 (EST) Received: from ms8.netsolmail.com (localhost.netsolmail.com [127.0.0.1]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AUK43895; Wed, 24 Mar 2004 18:24:18 -0500 (EST) From: Message-Id: <200403242324.AUK43895@ms8.netsolmail.com> Received: from 65.104.102.243 by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with HTTP/1.1; Wed, 24 Mar 2004 18:24:18 -0500 Date: Wed, 24 Mar 2004 18:24:18 -0500 Subject: switching cache buffer 4096 -> 512 and visa versa... To: linux-xfs@oss.sgi.com X-Mailer: Webmail Mirapoint Direct 3.2.2-GA MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2563 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian@krusic.com Precedence: bulk X-list: linux-xfs Content-Length: 468 Lines: 21 Hi, I've read a few posts regarding this message. I'm using kernal v20-19.9.XFS1.3.0 with software raid and external log file v1. The -s size=4096 doesn't seem to be supported so I tried b size=4096. I've also tried v2 log but I then can't mount the fs. I'm no expert but have an entire facilty to build so I doubt that I will ever be one however I hope you all can help me out. How do I fix this? Bri- Krusic Consulting Inc. Network Consulting Services. From owner-linux-xfs@oss.sgi.com Wed Mar 24 15:47:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 15:47:53 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2ONllKO004980 for ; Wed, 24 Mar 2004 15:47:47 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2ONi5f0032241 for ; Wed, 24 Mar 2004 17:44:05 -0600 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA14956; Thu, 25 Mar 2004 10:44:03 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2ONhxFx626168; Thu, 25 Mar 2004 10:43:59 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i2ONhIME001018; Thu, 25 Mar 2004 10:43:18 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i2ONhHU6001016; Thu, 25 Mar 2004 10:43:17 +1100 Date: Thu, 25 Mar 2004 10:43:17 +1100 From: Nathan Scott To: brian@krusic.com Cc: linux-xfs@oss.sgi.com Subject: Re: switching cache buffer 4096 -> 512 and visa versa... Message-ID: <20040324234317.GA715@frodo> References: <200403242324.AUK43895@ms8.netsolmail.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403242324.AUK43895@ms8.netsolmail.com> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2564 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 504 Lines: 20 On Wed, Mar 24, 2004 at 06:24:18PM -0500, brian@krusic.com wrote: > Hi, > > I've read a few posts regarding this message. I'm using > kernal v20-19.9.XFS1.3.0 with software raid and external log > file v1. > > The -s size=4096 doesn't seem to be supported so I tried b > size=4096. > > I've also tried v2 log but I then can't mount the fs. -ssize was right. Grab a current kernel, and if it still doesn't mount, send your xfs_info and the mount failure message from dmesg. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Mar 24 16:25:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 16:25:10 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2P0P3KO009226 for ; Wed, 24 Mar 2004 16:25:05 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2P2Rxmv001836 for ; Wed, 24 Mar 2004 18:28:00 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA16039; Thu, 25 Mar 2004 11:24:54 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2P0OoFx656599; Thu, 25 Mar 2004 11:24:51 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i2P0O6ME001175; Thu, 25 Mar 2004 11:24:06 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i2P0O44F001173; Thu, 25 Mar 2004 11:24:04 +1100 Date: Thu, 25 Mar 2004 11:24:04 +1100 From: Nathan Scott To: Steve Wray Cc: linux-xfs@oss.sgi.com Subject: Re: trying to diagnose cause of xfs filesystem corruption Message-ID: <20040325002404.GC715@frodo> References: <200403250947.34759.stevew@catalyst.net.nz> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403250947.34759.stevew@catalyst.net.nz> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2565 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1176 Lines: 32 On Thu, Mar 25, 2004 at 09:47:34AM +1200, Steve Wray wrote: > We have a machine with; > SATA, software raid, LVM2 and XFS filesystems. > LVM2 is appropriately configured to work on software raid. > > We see corruption on XFS filesystems on real partitions on normal IDE drives > (not SATA and no software RAID or LVM) as well as on LVM volumes on SATA > drives. > > Corruption occurs during normal use, there have been no power or kernel panic > problems. hi there, Any chance you have a reproducible test case for hitting this? The output from xfs_db on that inode (21214761) would be useful information too. Also the xfs_db superblock dump (or xfs_info output) would be handy. > The kernel is 2.6.4 > > We are seeing problems with the XFS filesystems like this for example; > > Mar 21 07:00:05 plato kernel: Filesystem "dm-0": corrupt dinode 21214761, extent total = 1025, nblocks = 2. Unmount and run xfs_repair. > Mar 21 07:00:05 plato kernel: 0x0: 49 4e 81 b4 01 02 00 01 00 00 04 10 00 00 00 64 > Mar 21 07:00:05 plato kernel: Filesystem "dm-0": XFS internal error xfs_iformat(1) at line 475 of file fs/xfs/xfs_inode.c. Caller 0xc0240\ thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Mar 24 16:48:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 16:48:22 -0800 (PST) Received: from mail2.catalyst.net.nz (godel.catalyst.net.nz [202.49.159.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2P0mHKO010436 for ; Wed, 24 Mar 2004 16:48:18 -0800 Received: from leibniz.catalyst.net.nz ([202.49.159.7] helo=shankara.wgtn.cat-it.co.nz) by mail2.catalyst.net.nz with esmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.35 #1 (Debian)) id 1B6J2Y-0006MS-02 for ; Thu, 25 Mar 2004 12:48:10 +1200 From: Steve Wray Reply-To: stevew@catalyst.net.nz To: linux-xfs@oss.sgi.com Subject: Re: trying to diagnose cause of xfs filesystem corruption Date: Thu, 25 Mar 2004 12:48:10 +1200 User-Agent: KMail/1.5 References: <200403250947.34759.stevew@catalyst.net.nz> <20040325002404.GC715@frodo> In-Reply-To: <20040325002404.GC715@frodo> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200403251248.10313.stevew@catalyst.net.nz> X-System-Filter-Id: mail2.catalyst.net.nz 1B6J2Y-0006MS-02 X-Virus-Scanned-By: Amavis with CLAM Anti Virus on mail2.catalyst.net.nz X-archive-position: 2566 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stevew@catalyst.net.nz Precedence: bulk X-list: linux-xfs Content-Length: 1334 Lines: 40 On Thu, 25 Mar 2004 12:24, Nathan Scott wrote: > On Thu, Mar 25, 2004 at 09:47:34AM +1200, Steve Wray wrote: > > We have a machine with; > > SATA, software raid, LVM2 and XFS filesystems. > > LVM2 is appropriately configured to work on software raid. > > > > We see corruption on XFS filesystems on real partitions on normal > > IDE drives (not SATA and no software RAID or LVM) as well as on > > LVM volumes on SATA drives. > > > > Corruption occurs during normal use, there have been no power or > > kernel panic problems. > > hi there, > > Any chance you have a reproducible test case for hitting this? Well, if we leave it up overnight there will always be some in the mornings :-/ > The output from xfs_db on that inode (21214761) would be useful > information too. Also the xfs_db superblock dump (or xfs_info > output) would be handy. I have no idea how to interpret from the error message to the filesystem. The log entries report things like; Filesystem "dm-0" How do I interpret dm-0 as a /dev entry? I am guessing that what I see in this entry in /dev/mapper; brw------- 1 root root 253, 0 Mar 22 10:37 vg0-lv_home might imply that dm-0 refers to /dev/vg0/lv_home (an xfs filesystem that has had these errors). However I'm not sure where I see the log entries for /var (on /dev/hda5) in there... From owner-linux-xfs@oss.sgi.com Wed Mar 24 17:19:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 17:19:58 -0800 (PST) Received: from smtp02.syd.iprimus.net.au (smtp02.syd.iprimus.net.au [210.50.76.52]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2P1JsKO011650 for ; Wed, 24 Mar 2004 17:19:55 -0800 Received: from mitta.sydney (211.26.149.22) by smtp02.syd.iprimus.net.au (7.0.024) id 402CF87000D5AE1F; Thu, 25 Mar 2004 12:19:49 +1100 Received: from mitta.sydney (localhost [127.0.0.1]) by mitta.sydney (8.12.11/8.12.4) with ESMTP id i2P1Jlg5004675; Thu, 25 Mar 2004 12:19:47 +1100 Received: (from alciocca@localhost) by mitta.sydney (8.12.11/8.12.11/Submit) id i2P1JlfE004674; Thu, 25 Mar 2004 12:19:47 +1100 Date: Thu, 25 Mar 2004 12:19:47 +1100 From: Adam Cioccarelli To: Steve Wray Cc: linux-xfs@oss.sgi.com Subject: Re: trying to diagnose cause of xfs filesystem corruption Message-ID: <20040325011947.GA4664@gmx.net> References: <200403250947.34759.stevew@catalyst.net.nz> <20040325002404.GC715@frodo> <200403251248.10313.stevew@catalyst.net.nz> Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <200403251248.10313.stevew@catalyst.net.nz> User-Agent: Mutt/1.5.6i Content-Transfer-Encoding: 8bit X-archive-position: 2567 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alciocca@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 1602 Lines: 48 Hi, if you cat /proc/partitions you get the major and minor numbers for dm-0, then ls -l /dev/mapper/ to match the vg. Adam On Thu, Mar 25, 2004 at 12:48:10PM +1200, Steve Wray wrote: > On Thu, 25 Mar 2004 12:24, Nathan Scott wrote: > > On Thu, Mar 25, 2004 at 09:47:34AM +1200, Steve Wray wrote: > > > We have a machine with; > > > SATA, software raid, LVM2 and XFS filesystems. > > > LVM2 is appropriately configured to work on software raid. > > > > > > We see corruption on XFS filesystems on real partitions on normal > > > IDE drives (not SATA and no software RAID or LVM) as well as on > > > LVM volumes on SATA drives. > > > > > > Corruption occurs during normal use, there have been no power or > > > kernel panic problems. > > > > hi there, > > > > Any chance you have a reproducible test case for hitting this? > > Well, if we leave it up overnight there will always be some in the > mornings :-/ > > > The output from xfs_db on that inode (21214761) would be useful > > information too. Also the xfs_db superblock dump (or xfs_info > > output) would be handy. > > I have no idea how to interpret from the error message to the > filesystem. The log entries report things like; > > Filesystem "dm-0" > > How do I interpret dm-0 as a /dev entry? > > I am guessing that what I see in this entry in /dev/mapper; > brw------- 1 root root 253, 0 Mar 22 10:37 vg0-lv_home > > might imply that dm-0 refers to /dev/vg0/lv_home (an xfs filesystem that > has had these errors). > > However I'm not sure where I see the log entries for /var (on /dev/hda5) > in there... > From owner-linux-xfs@oss.sgi.com Wed Mar 24 17:50:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 17:50:31 -0800 (PST) Received: from ns1.tippett.com (user-112vvgq.biz.mindspring.com [66.47.254.26]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2P1oPKO012629 for ; Wed, 24 Mar 2004 17:50:27 -0800 Received: from hermes.tippett.com (hermes-e.tippett.com [192.168.3.20]) by ns1.tippett.com (8.12.8/8.12.8) with ESMTP id i2P1YnGN008078 for ; Wed, 24 Mar 2004 17:34:49 -0800 Received: from tippett.com (gangsta.tippett.com [192.168.3.62]) by hermes.tippett.com (980427.SGI.8.8.8/8.7.3) with ESMTP id RAA77384 for ; Wed, 24 Mar 2004 17:50:09 -0800 (PST) Message-ID: <40623ACE.6010301@tippett.com> Date: Wed, 24 Mar 2004 17:50:06 -0800 From: Christian Rice Organization: Tippett Studio User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfsdump/xfsrestore and open_by_handle Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.39 X-archive-position: 2568 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xian@tippett.com Precedence: bulk X-list: linux-xfs Content-Length: 2707 Lines: 64 This is RedHat 9.0, with 2.4.23, xfs patches from cvs snapshot on 11/30/03, and xfsdump-2.2.16-1 I'm seeing some wierd output when cloning disks. I just moved up from RedHat 7.3 to RedHat9, and this is a new issue. Here's some output: [root@gangsta hdc1]# xfsdump -J - /dev/hda1 | xfsrestore - . xfsrestore: using file dump (drive_simple) strategy xfsrestore: version 2.2.16 (dump format 3.0) - Running single-threaded xfsdump: using file dump (drive_simple) strategy xfsdump: version 2.2.16 (dump format 3.0) - Running single-threaded xfsdump: level 0 dump of gangsta:/boot xfsrestore: searching media for dump xfsdump: dump date: Wed Mar 24 17:39:06 2004 xfsdump: session id: 6422a58d-c3f5-4fb5-afc5-1f19cdff9916 xfsdump: session label: "" xfsdump: ino map phase 1: skipping (no subtrees specified) xfsdump: ino map phase 2: constructing initial dump list xfsdump: ino map phase 3: skipping (no pruning necessary) xfsdump: ino map phase 4: skipping (size estimated in phase 2) xfsdump: ino map phase 5: skipping (only one dump stream) xfsdump: ino map construction complete xfsdump: estimated dump size: 11100032 bytes xfsdump: creating dump session media file 0 (media 0, file 0) xfsdump: dumping ino map xfsdump: dumping directories xfsdump: dumping non-directory files xfsrestore: examining media file 0 xfsrestore: dump description: xfsrestore: hostname: gangsta xfsrestore: mount point: /boot xfsrestore: volume: /dev/hda1 xfsrestore: session time: Wed Mar 24 17:39:06 2004 xfsrestore: level: 0 xfsrestore: session label: "" xfsrestore: media label: "" xfsrestore: file system id: 9059d117-0a62-4cfd-a09f-e373c3b1aaa7 xfsrestore: session id: 6422a58d-c3f5-4fb5-afc5-1f19cdff9916 xfsrestore: media id: dc405d5f-5003-4dbd-8d37-71428af5e72a xfsrestore: searching media for directory dump xfsrestore: reading directories xfsrestore: 3 directories and 37 entries processed xfsrestore: directory post-processing xfsrestore: restoring non-directory files xfsdump: ending media file xfsdump: media file size 11067488 bytes xfsdump: dump size (non-dir files) : 11034512 bytes xfsdump: dump complete: 0 seconds elapsed xfsdump: Dump Status: SUCCESS xfsrestore: WARNING: open_by_handle of lost+found failed:Bad file descriptor xfsrestore: WARNING: open_by_handle of grub failed:Bad file descriptor xfsrestore: restore complete: 0 seconds elapsed xfsrestore: Restore Status: SUCCESS [root@gangsta hdc1]# The files and directories do appear intact, though, to the casual diff... When I clone the '/' directory (hda3 -> hdc3), I get many screens full of similar open_by_handle messages. I'm going to try another xfs_repair. There doesn't seem to be any visible adverse effects at this point, though. From owner-linux-xfs@oss.sgi.com Wed Mar 24 18:26:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 18:26:22 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2P2QIKO013939 for ; Wed, 24 Mar 2004 18:26:18 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2P4TFIe020358 for ; Wed, 24 Mar 2004 20:29:16 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2P2QAAL25045007 for ; Thu, 25 Mar 2004 13:26:10 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2P2Q94920267032 for linux-xfs@oss.sgi.com; Thu, 25 Mar 2004 13:26:09 +1100 (EST) Date: Thu, 25 Mar 2004 13:26:09 +1100 (EST) From: Nathan Scott Message-Id: <200403250226.i2P2Q94920267032@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: PARTIAL TAKE 911290 - Reenable non-block flag for DMAPI. X-archive-position: 2569 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 523 Lines: 22 Date: Wed Mar 24 18:24:32 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-xfs-linux Inspected by: hch@lst.de roehrich@sgi.com gnb@sgi.com Undoes mod: lbs:xfs-kern:169029a Author: nathans Merged by: nathans Merged mods: lbs:xfs-kern:169033a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:169033a dmapi/dmapi_session.c - 1.17 dmapi/dmapi_private.h - 1.14 linux-2.4/xfs_iops.c - 1.205 - Merge of lbs:xfs-kern:169033a by nathans. From owner-linux-xfs@oss.sgi.com Wed Mar 24 18:43:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 18:43:22 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2P2hDKO014816 for ; Wed, 24 Mar 2004 18:43:14 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2P3iUiQ019052 for ; Wed, 24 Mar 2004 19:44:31 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA18185; Thu, 25 Mar 2004 13:43:04 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2P2h0Fx657590; Thu, 25 Mar 2004 13:43:01 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i2P2gIME001512; Thu, 25 Mar 2004 13:42:18 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i2P2gHOF001510; Thu, 25 Mar 2004 13:42:17 +1100 Date: Thu, 25 Mar 2004 13:42:17 +1100 From: Nathan Scott To: Christian Rice Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump/xfsrestore and open_by_handle Message-ID: <20040325024217.GD715@frodo> References: <40623ACE.6010301@tippett.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40623ACE.6010301@tippett.com> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2570 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 439 Lines: 15 On Wed, Mar 24, 2004 at 05:50:06PM -0800, Christian Rice wrote: > This is RedHat 9.0, with 2.4.23, xfs patches from cvs snapshot on > 11/30/03, and xfsdump-2.2.16-1 > > I'm seeing some wierd output when cloning disks. I just moved up from > RedHat 7.3 to RedHat9, and this is a new issue. This is fixed in xfsdump-2.2.17 or later (you will also need xfsprogs-2.6.4 or later and, IIRC, attr-2.4.14 or later too). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Mar 24 19:14:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 19:14:48 -0800 (PST) Received: from mail2.catalyst.net.nz (godel.catalyst.net.nz [202.49.159.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2P3EYKO021724 for ; Wed, 24 Mar 2004 19:14:35 -0800 Received: from leibniz.catalyst.net.nz ([202.49.159.7] helo=shankara.wgtn.cat-it.co.nz) by mail2.catalyst.net.nz with esmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.35 #1 (Debian)) id 1B6LK8-0003cU-02 for ; Thu, 25 Mar 2004 15:14:28 +1200 From: Steve Wray Reply-To: stevew@catalyst.net.nz To: linux-xfs@oss.sgi.com Subject: Re: trying to diagnose cause of xfs filesystem corruption Date: Thu, 25 Mar 2004 15:14:27 +1200 User-Agent: KMail/1.5 References: <200403250947.34759.stevew@catalyst.net.nz> <200403251248.10313.stevew@catalyst.net.nz> <20040325011947.GA4664@gmx.net> In-Reply-To: <20040325011947.GA4664@gmx.net> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200403251514.27618.stevew@catalyst.net.nz> X-System-Filter-Id: mail2.catalyst.net.nz 1B6LK8-0003cU-02 X-Virus-Scanned-By: Amavis with CLAM Anti Virus on mail2.catalyst.net.nz X-archive-position: 2571 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stevew@catalyst.net.nz Precedence: bulk X-list: linux-xfs Content-Length: 250 Lines: 9 On Thu, 25 Mar 2004 13:19, Adam Cioccarelli wrote: > Hi, > > if you cat /proc/partitions you get the major and minor numbers for > dm-0, then ls -l /dev/mapper/ to match the vg. Yup, I figured that part out, but how about the /dev/hda5 partition? From owner-linux-xfs@oss.sgi.com Wed Mar 24 19:49:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 19:49:54 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2P3npKO023994 for ; Wed, 24 Mar 2004 19:49:51 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2P3nif0020615 for ; Wed, 24 Mar 2004 21:49:45 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2P3ngAL25033746 for ; Thu, 25 Mar 2004 14:49:43 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2P3ngCf25117921 for linux-xfs@oss.sgi.com; Thu, 25 Mar 2004 14:49:42 +1100 (EST) Date: Thu, 25 Mar 2004 14:49:42 +1100 (EST) From: Nathan Scott Message-Id: <200403250349.i2P3ngCf25117921@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs-2.6.8 X-archive-position: 2572 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2174 Lines: 89 Merge fix for xfs_bmap verbose mode stripe alignment calculations. Date: Tue Mar 23 14:43:38 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: cwf Author: jpk Merged by: nathans Merged mods: grove2:eoe:168926a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:168926a xfsprogs/io/bmap.c - 1.6 Fix a typo on the xfs(5) man page. Date: Tue Mar 23 14:48:14 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:168968a xfsprogs/man/man5/xfs.5 - 1.9 Fix xfs_db when examining v2 dirs with bsize larger than a fsb. Date: Wed Mar 24 19:45:28 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:169041a xfsprogs/db/faddr.c - 1.10 xfs_io tweaks - support multiple files and memory mapped IO, amongst other odds and ends. Date: Wed Mar 24 19:48:10 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:169042a xfsprogs/io/inject.c - 1.1 xfsprogs/io/shutdown.c - 1.1 xfsprogs/io/file.c - 1.1 xfsprogs/io/fadvise.c - 1.1 xfsprogs/io/io.h - 1.1 xfsprogs/io/xfs_freeze.sh - 1.1 xfsprogs/io/mmap.c - 1.1 xfsprogs/Makefile - 1.21 xfsprogs/VERSION - 1.102 xfsprogs/doc/CHANGES - 1.139 xfsprogs/debian/changelog - 1.92 xfsprogs/man/man8/xfs_io.8 - 1.3 xfsprogs/io/command.c - 1.5 xfsprogs/io/command.h - 1.6 xfsprogs/io/pread.c - 1.11 xfsprogs/io/input.h - 1.5 xfsprogs/io/Makefile - 1.5 xfsprogs/io/truncate.c - 1.7 xfsprogs/io/resblks.c - 1.7 xfsprogs/io/quit.c - 1.5 xfsprogs/io/pwrite.c - 1.11 xfsprogs/io/prealloc.c - 1.7 xfsprogs/io/help.c - 1.5 xfsprogs/io/input.c - 1.7 xfsprogs/io/init.h - 1.5 xfsprogs/io/open.c - 1.11 xfsprogs/io/init.c - 1.7 xfsprogs/io/bmap.c - 1.7 xfsprogs/io/fsync.c - 1.5 From owner-linux-xfs@oss.sgi.com Wed Mar 24 19:55:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 19:55:25 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2P3tMKO024479 for ; Wed, 24 Mar 2004 19:55:23 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2P5wIWm031978 for ; Wed, 24 Mar 2004 21:58:21 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2P3t9AL25095071; Thu, 25 Mar 2004 14:55:10 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2P3t8X019215171; Thu, 25 Mar 2004 14:55:08 +1100 (EST) Date: Thu, 25 Mar 2004 14:55:08 +1100 (EST) From: Nathan Scott Message-Id: <200403250355.i2P3t8X019215171@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 910630 - pagebuf X-archive-position: 2573 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 586 Lines: 20 Fix delayed write buffer handling to use the correct list interfaces, add validity checks, remove unused code, and fix comments. Date: Wed Mar 24 19:54:00 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux Inspected by: hch@lst.de,cattelan@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:169043a xfs_vfsops.c - 1.446 linux-2.6/xfs_super.c - 1.299 linux-2.4/xfs_super.c - 1.284 linux-2.6/xfs_buf.h - 1.92 linux-2.6/xfs_buf.c - 1.160 linux-2.4/xfs_buf.h - 1.99 linux-2.4/xfs_buf.c - 1.181 From owner-linux-xfs@oss.sgi.com Wed Mar 24 22:05:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 22:05:56 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2P65rKO031486 for ; Wed, 24 Mar 2004 22:05:53 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2P65kf0027286 for ; Thu, 25 Mar 2004 00:05:47 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2P65iAL24931015 for ; Thu, 25 Mar 2004 17:05:45 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2P65i4s25102675 for linux-xfs@oss.sgi.com; Thu, 25 Mar 2004 17:05:44 +1100 (EST) Date: Thu, 25 Mar 2004 17:05:44 +1100 (EST) From: Nathan Scott Message-Id: <200403250605.i2P65i4s25102675@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 910630 - build fix X-archive-position: 2574 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 332 Lines: 13 Ack, fix patch induced confusion in merged header. Date: Wed Mar 24 22:05:12 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:169047a linux-2.6/xfs_buf.h - 1.93 From owner-linux-xfs@oss.sgi.com Wed Mar 24 22:16:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 22:16:57 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2P6GtKO032104 for ; Wed, 24 Mar 2004 22:16:55 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2P6FOf0032001 for ; Thu, 25 Mar 2004 00:15:25 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2P6FNAL25021322 for ; Thu, 25 Mar 2004 17:15:23 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2P6FMDc15128041 for linux-xfs@oss.sgi.com; Thu, 25 Mar 2004 17:15:22 +1100 (EST) Date: Thu, 25 Mar 2004 17:15:22 +1100 (EST) From: Nathan Scott Message-Id: <200403250615.i2P6FMDc15128041@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 911624 - log error check X-archive-position: 2575 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 333 Lines: 13 Reinstate some accidentally dropped log IO error injection code. Date: Wed Mar 24 22:15:01 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux Inspected by: tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:169048a xfs_log.c - 1.291 From owner-linux-xfs@oss.sgi.com Wed Mar 24 22:37:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 22:37:46 -0800 (PST) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.227]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2P6bfKO000575 for ; Wed, 24 Mar 2004 22:37:41 -0800 Received: by heretic.physik.fu-berlin.de (8.12.10/8.12.10) with ESMTP id i2P6bT6d022471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Mar 2004 07:37:33 +0100 Received: (from thimm@localhost) by neu.nirvana (8.12.10/8.12.10/Submit) id i2P6bRgY025955; Thu, 25 Mar 2004 07:37:27 +0100 Date: Thu, 25 Mar 2004 07:37:26 +0100 From: Axel Thimm To: Kjell Randa Cc: linux-xfs@oss.sgi.com, Takeru KOMORIYA , Dan Yocum Subject: Re: Kernel oops in 2.4.22-1.2174.nptl_37.rhfc1.atsmp Message-ID: <20040325063726.GA23797@neu.nirvana> References: <405E219A.7080607@broadpark.no> Mime-Version: 1.0 Content-type: text/plain Content-Disposition: inline In-Reply-To: <405E219A.7080607@broadpark.no> User-Agent: Mutt/1.4.2i Content-Transfer-Encoding: 8bit X-archive-position: 2576 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@ATrpms.net Precedence: bulk X-list: linux-xfs Content-Length: 7687 Lines: 174 On Mon, Mar 22, 2004 at 12:13:30AM +0100, Kjell Randa wrote: > I have been using XFS for more than two years without any problems, but > lately I have started to get oops messages during time of heavy I/O > load. The system survives and seems healty afterwords. This may be > related to upgrade to the current kernel. What was the kernel running before the upgrade? An atrpms kernel or something else? > System is a dual P3 866 MHz on av Via board using 4 Western Digital ide > disks (2x160 Mb + 2x80GB) connect to a IDE PCI controller from HighPoint > (Rocket133 with a Silicon Image chip SiI680) > > The disks are configured in raid1 (software), lvm and filesystems > formatted with XFS. > > System is running Fedore Core1 with kernel downloaded from > http://atrpms.physik.fu-berlin.de/dist/fc1/ > > This kernel conains the following patches: > * base kernel sources: Taken from Fedora Core 1 > * XFS: merged patches found in 1.3.1 > * i2c-2.8.4 and lm_sensors-2.8.4. You should also get the updated > userland tools and updated kernel modules. > * Linux Extended Attributes and ACLs 0.8.65. > * LVM 1.0.7 (courtesy of Komoriya Takeru) > * v4l2-api (from http://bytesex.org/v4l/) > * PlanetCCRMA caps patches: capabilities, drm low latency and others. > * linux-ntfs 2.1.4c > * bootsplash > > kernet is tainted by the Nividia binary driver. > > I am not shure if this is a XFS problems or could be related to some > other patches (lvm), but not beeing a kernel hacker I hope somebody can > take take look on the ksymoops output and give their opinion. While the atrpms kernels, both up and smp seem to work very stable, I had another report about the RH9 kernel and lvm/md. So there seems to be some problem in that combination. I am copying the lvm patch maintainer. Could you test the FC1 kernel? It works fine in RH9 environments. > ksymoops 2.4.5 on i686 2.4.22-1.2174.nptl_37.rhfc1.atsmp. Options used > -V (default) > -k /proc/ksyms (default) > -l /proc/modules (default) > -o /lib/modules/2.4.22-1.2174.nptl_37.rhfc1.atsmp/ (default) > -m /boot/System.map-2.4.22-1.2174.nptl_37.rhfc1.atsmp (default) > > Warning: You did not tell me where to find symbol information. I will > assume that the log matches the kernel and modules that are running > right now and I'll use the default options above for symbol resolution. > If the current kernel and/or modules do not match the log, you can get > more accurate output by telling me the kernel version and where to find > map, modules, ksyms etc. ksymoops -h explains the options. > > Error (expand_objects): cannot stat(/lib/ext3.o) for ext3 > ksymoops: No such file or directory > Error (expand_objects): cannot stat(/lib/jbd.o) for jbd > ksymoops: No such file or directory > Error (expand_objects): cannot stat(/lib/raid1.o) for raid1 > ksymoops: No such file or directory > Error (expand_objects): cannot stat(/lib/lvm-mod.o) for lvm-mod > ksymoops: No such file or directory > Warning (compare_maps): ksyms_base symbol dmi_broken_R__ver_dmi_broken > not found in System.map. Ignoring ksyms_base entry > Warning (map_ksym_to_module): cannot match loaded module ext3 to a > unique module object. Trace may not be reliable. > Mar 21 04:07:16 eagle nmbd[1089]: Got SIGHUP dumping debug info. > Mar 21 04:46:17 eagle kernel: Unable to handle kernel NULL pointer > dereference at virtual address 00000006 > Mar 21 04:46:17 eagle kernel: f0a00b70 > Mar 21 04:46:17 eagle kernel: *pde = 00000000 > Mar 21 04:46:17 eagle kernel: Oops: 0000 > Mar 21 04:46:17 eagle kernel: CPU: 1 > Mar 21 04:46:17 eagle kernel: EIP: 0060:[] Tainted: P > Using defaults from ksymoops -t elf32-i386 -a i386 > Mar 21 04:46:17 eagle kernel: EFLAGS: 00010256 > Mar 21 04:46:17 eagle kernel: eax: 00000000 ebx: 00000002 ecx: > c9325dbc edx: ffffffff > Mar 21 04:46:17 eagle kernel: esi: ec557900 edi: 00000000 ebp: > 00000000 esp: c9325d84 > Mar 21 04:46:17 eagle kernel: ds: 0068 es: 0068 ss: 0068 > Mar 21 04:46:17 eagle kernel: Process f-prot (pid: 28833, > stackpage=c9325000) > Mar 21 04:46:17 eagle kernel: Stack: df460b14 00000000 00000000 00001000 > 00000001 c9325dc0 c9325dbc d2a01380 > Mar 21 04:46:17 eagle kernel: ef85b000 00000246 d2a01394 00000002 > ffffffff ffffffff 00000001 ffffffff > Mar 21 04:46:17 eagle kernel: ffffffff 00000000 00000000 00000000 > 00000000 00001000 00000002 ec557900 > Mar 21 04:46:17 eagle kernel: Call Trace: [] > linvfs_get_block [xfs] 0x37 (0xc9325df0) > Mar 21 04:46:17 eagle kernel: [] block_read_full_page [kernel] > 0x2b6 (0xc9325e0c) > Mar 21 04:46:18 eagle kernel: [] do_generic_file_read [kernel] > 0x239 (0xc9325e70) > Mar 21 04:46:18 eagle kernel: [] linvfs_get_block [xfs] 0x0 > (0xc9325e78) > Mar 21 04:46:18 eagle kernel: [] file_read_actor [kernel] 0x0 > (0xc9325ea0) > Mar 21 04:46:18 eagle kernel: [] generic_file_new_read > [kernel] 0xc5 (0xc9325ec0) > Mar 21 04:46:18 eagle kernel: [] file_read_actor [kernel] 0x0 > (0xc9325ed0) > Mar 21 04:46:18 eagle kernel: [] dput [kernel] 0x30 (0xc9325ed8) > Mar 21 04:46:18 eagle kernel: [] generic_file_read [kernel] > 0x2f (0xc9325f0c) > Mar 21 04:46:18 eagle kernel: [] xfs_read [xfs] 0x133 (0xc9325f24) > Mar 21 04:46:18 eagle kernel: [] linvfs_read [xfs] 0x72 > (0xc9325f64) > Mar 21 04:46:18 eagle kernel: [] sys_read [kernel] 0x97 > (0xc9325f94) > Mar 21 04:46:18 eagle kernel: [] system_call [kernel] 0x33 > (0xc9325fc0) > Mar 21 04:46:18 eagle kernel: Code: 0f b7 40 06 66 89 46 0c 8b 44 24 7c > 85 c0 74 2e f7 46 18 11 > > > >>EIP; f0a00b70 <[xfs]linvfs_get_block_core+1c0/270> <===== > > >>ecx; c9325dbc <_end+8e63944/3034cbe8> > >>edx; ffffffff > >>esi; ec557900 <_end+2c095488/3034cbe8> > >>esp; c9325d84 <_end+8e6390c/3034cbe8> > > Trace; f0a00c57 <[xfs]linvfs_get_block+37/40> > Trace; c0153f26 > Trace; c013e179 > Trace; f0a00c20 <[xfs]linvfs_get_block+0/40> > Trace; c013e7c0 > Trace; c013e985 > Trace; c013e7c0 > Trace; c0167b20 > Trace; c013eaaf > Trace; f0a06e53 <[xfs]xfs_read+133/2f0> > Trace; f0a015e2 <[xfs]linvfs_read+72/f0> > Trace; c01504f7 > Trace; c0109b27 > > Code; f0a00b70 <[xfs]linvfs_get_block_core+1c0/270> > 00000000 <_EIP>: > Code; f0a00b70 <[xfs]linvfs_get_block_core+1c0/270> <===== > 0: 0f b7 40 06 movzwl 0x6(%eax),%eax <===== > Code; f0a00b74 <[xfs]linvfs_get_block_core+1c4/270> > 4: 66 89 46 0c mov %ax,0xc(%esi) > Code; f0a00b78 <[xfs]linvfs_get_block_core+1c8/270> > 8: 8b 44 24 7c mov 0x7c(%esp,1),%eax > Code; f0a00b7c <[xfs]linvfs_get_block_core+1cc/270> > c: 85 c0 test %eax,%eax > Code; f0a00b7e <[xfs]linvfs_get_block_core+1ce/270> > e: 74 2e je 3e <_EIP+0x3e> > Code; f0a00b80 <[xfs]linvfs_get_block_core+1d0/270> > 10: f7 46 18 11 00 00 00 testl $0x11,0x18(%esi) > > > 3 warnings and 4 errors issued. Results may not be reliable. > > -- Axel.Thimm at ATrpms.net -- Attached file included as plaintext by Ecartis -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAYn4mQBVS1GOamfERAnX1AJwOZTtATq+eY3YfzsmcCHWFm19+8QCgi39P rJkKgbOJ7CKSNtH6RCvMsEk= =3pwb -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Mar 24 22:39:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 22:39:12 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2P6d7KO000861 for ; Wed, 24 Mar 2004 22:39:09 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 6E105FB83A; Thu, 25 Mar 2004 00:39:02 -0600 (CST) Date: Wed, 24 Mar 2004 22:39:02 -0800 From: Chris Wedgwood To: "IKARASHI, Seiichi" Cc: linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS Message-ID: <20040325063902.GA9697@dingdong.cryptoapps.com> References: <4060F7FC.8090602@miraclelinux.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4060F7FC.8090602@miraclelinux.com> Content-Transfer-Encoding: 8bit X-archive-position: 2577 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 574 Lines: 23 On Wed, Mar 24, 2004 at 11:52:44AM +0900, IKARASHI, Seiichi wrote: > How do you guys synchronize a XFS partition? sync() of xfs_freeze depending on what you want > I'm stacking 'cause XFS partitions seem to take longer time than > other filesystems like ext3 or reiserfs to really write down to HDD. it depends what your doing, but for me i never noticed a significant difference > Repeating sync() does not take effect. > Is there any specific command or operation to sync XFS? sync() should work --- why do you think it does? what kernel version are you using? From owner-linux-xfs@oss.sgi.com Wed Mar 24 22:41:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Mar 2004 22:41:08 -0800 (PST) Received: from ms-smtp-02.tampabay.rr.com (ms-smtp-02-smtplb.tampabay.rr.com [65.32.5.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2P6f2KO001425 for ; Wed, 24 Mar 2004 22:41:03 -0800 Received: from lexx.gnuorder.net (6532127hfc125.tampabay.rr.com [65.32.127.125]) by ms-smtp-02.tampabay.rr.com (8.12.10/8.12.7) with SMTP id i2P6f082024004 for ; Thu, 25 Mar 2004 01:41:00 -0500 (EST) Date: Thu, 25 Mar 2004 01:41:00 -0500 From: Greg Koch To: linux-xfs@oss.sgi.com Subject: losing disk space Message-Id: <20040325014100.0aaedcea.gkoch@tampabay.rr.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-archive-position: 2578 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gkoch@tampabay.rr.com Precedence: bulk X-list: linux-xfs Content-Length: 1105 Lines: 27 I have a server running apache on an 18GB xfs partition. It seems to loose large chunks of disk space around the time the apache logs rotate. The apache logs get to be around 2 gig at the end of the day and are compressed and started over by logrotate. df reports one value while du-sch / reports another. The value du give stays pretty much steady while the value df gives shows a gradual loss of disk space. The last time the disk filled up, I restarted and used xfs-repair which recovered a bunch of apache logs among other stuff. The disk has plenty of room now and on most days seems to recover disk space after the log rotation. Then on some days you dont see any space recovery. Here are some other details: Gentoo kernel Linux 2.4.25_pre7-gss-r2 Dual Xeon 1.8 GHz CPU WDC WD200BB-00CAA1 hard drive in udma5 mode WriteCache=enabled xfsprogs 2.3.9 logrotate 3.6.5 syslogd 1.4.1 apache 2.0.48 -- My colleagues, every statement I make today is backed up by sources, solid sources. These are not assertions. What we are giving you are facts and conclusions based on solid intelligence. From owner-linux-xfs@oss.sgi.com Thu Mar 25 00:33:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 00:33:34 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2P8XLKO009584 for ; Thu, 25 Mar 2004 00:33:21 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2P8XLcE009583 for linux-xfs@oss.sgi.com; Thu, 25 Mar 2004 00:33:21 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2P8XJKQ009569 for ; Thu, 25 Mar 2004 00:33:19 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2P810ZA005558; Thu, 25 Mar 2004 00:01:00 -0800 Date: Thu, 25 Mar 2004 00:01:00 -0800 Message-Id: <200403250801.i2P810ZA005558@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 320] xfsinvutil -i crash with segfault X-Bugzilla-Reason: AssignedTo X-archive-position: 2580 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2935 Lines: 74 http://oss.sgi.com/bugzilla/show_bug.cgi?id=320 ------- Additional Comments From nathans@sgi.com 2004-24-03 13:56 PDT ------- Created an attachment (id=112) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=112&action=view) initial xfsinvutil segv fix attempt That is pretty bizarre, not too much that looks like it could SEGV at that point, maybe your compiler is doing something wacko - does this patch help? thanks. ------- Additional Comments From Nicolas.Kowalski@imag.fr 2004-25-03 00:00 PDT ------- Unfortunately, the patch did not help. Here is the gdb backtrace I get this morning: gaspard:~# gdb xfsinvutil core GNU gdb 2002-04-01-cvs Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"... Core was generated by `xfsinvutil -i'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libuuid.so.1...done. Loaded symbols for /lib/libuuid.so.1 Reading symbols from /lib/libncurses.so.5...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x400c79ef in malloc () from /lib/libc.so.6 (gdb) bt #0 0x400c79ef in malloc () from /lib/libc.so.6 #1 0x400c7074 in malloc () from /lib/libc.so.6 #2 0x0804e874 in node_create (hidden=1, expanded=0, level=4, deleted=0, file_idx=1, text=0x8054fc0 ' ' , "media file: dlt7000", ops=0x8053320, parent=0x8054f68, children=0x0, nbr_children=0, data_idx=2) at list.c:68 #3 0x0804fdbf in generate_stobj_menu (startnode=0x8054218, level=2, StObjFileName=0x8054dd0 "/var/lib/xfsdump/inventory/4197c50d-45a6-45de-9992- 5a35c8c45d96.StObj") at stobj.c:505 #4 0x0804e322 in generate_invidx_menu ( inv_path=0x8053640 "/var/lib/xfsdump/inventory", startnode=0x8054b38, level=1, idxFileName=0x8053f38 "/var/lib/xfsdump/inventory/1bb54683-d619-4bbc-ba16-be 7e144229e1.InvIndex") at invidx.c:973 #5 0x0804c1f5 in generate_fstab_menu ( inv_path=0x8053640 "/var/lib/xfsdump/inventory", startnode=0x0, level=0, fstabname=0x8053d18 "/var/lib/xfsdump/inventory/fstab") at fstab.c:283 #6 0x0804b9e3 in generate_menu ( inv_path=0x8053640 "/var/lib/xfsdump/inventory") at cmenu.c:532 #7 0x0804bb1e in invutil_interactive ( inv_path=0x8053640 "/var/lib/xfsdump/inventory", mountpt=0x0, uuidp=0x0, timeSecs=0) at cmenu.c:587 #8 0x08049b5d in main (argc=2, argv=0xbffffd54) at invutil.c:216 Thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 25 02:53:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 02:53:12 -0800 (PST) Received: from jdc.local (dyn172.mel2.homedsl.pacific.net.au [203.100.245.172]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PAqxKO015784 for ; Thu, 25 Mar 2004 02:53:00 -0800 Received: from jdc.local (localhost [127.0.0.1]) by jdc.local (8.12.11/8.12.11/Debian-1) with ESMTP id i2PAqrNk004795; Thu, 25 Mar 2004 21:52:53 +1100 Received: (from jason@localhost) by jdc.local (8.12.11/8.12.11/Debian-1) id i2PAqrK5004787; Thu, 25 Mar 2004 21:52:53 +1100 From: Jason White MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Message-ID: <16482.47621.602520.162797@jdc.local> Date: Thu, 25 Mar 2004 21:52:53 +1100 To: Greg Koch Cc: linux-xfs@oss.sgi.com Subject: Re: losing disk space In-Reply-To: <20040325014100.0aaedcea.gkoch@tampabay.rr.com> References: <20040325014100.0aaedcea.gkoch@tampabay.rr.com> X-Mailer: VM 7.18 under Emacs 21.3.1 Reply-To: jasonw@ariel.ucs.unimelb.edu.au X-archive-position: 2581 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonw@ariel.ucs.unimelb.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 751 Lines: 18 Greg Koch writes: > I have a server running apache on an 18GB xfs partition. It seems to > loose large chunks of disk space around the time the apache logs rotate. > The apache logs get to be around 2 gig at the end of the day and are > compressed and started over by logrotate. df reports one value > while du-sch / reports another. The value du give stays pretty much > steady while the value df gives shows a gradual loss of disk space. > > The last time the disk filled up, I restarted and used xfs-repair which > recovered a bunch of apache logs among other stuff. While I don't want to preempt the experts here, the obvious questions are: Are there any xfs errors in your kernel logs? Can you post the output from xfs_repair? From owner-linux-xfs@oss.sgi.com Thu Mar 25 03:33:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 03:33:27 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2PBXMKO018074 for ; Thu, 25 Mar 2004 03:33:22 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2PBXMhg018073 for linux-xfs@oss.sgi.com; Thu, 25 Mar 2004 03:33:22 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2PBXKKO018057 for ; Thu, 25 Mar 2004 03:33:20 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2PAoVFA015715; Thu, 25 Mar 2004 02:50:31 -0800 Date: Thu, 25 Mar 2004 02:50:31 -0800 Message-Id: <200403251050.i2PAoVFA015715@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 321] New: XFS internal error, xfs_force_shutdown on 1.2TB fileserver. X-Bugzilla-Reason: AssignedTo X-archive-position: 2582 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 6663 Lines: 139 http://oss.sgi.com/bugzilla/show_bug.cgi?id=321 Summary: XFS internal error, xfs_force_shutdown on 1.2TB fileserver. Product: Linux XFS Version: 1.3.x Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: ericy@outblaze.com CC: ericy@outblaze.com I have a few 1.2TB (6*200GB) fileserver running RH7.3 with kernel 2.4.25 running 3ware 7506-8 RAID 1 * 3. The fileservers mainly contains users maildir with lots of subdirectories. Unfortunately I have been suffered from continuous filesystem corruption, following are the error messages from log: Mar 22 02:27:48 fs5-12 kernel: XFS internal error XFS_WANT_CORRUPTED_RETURN at line 295 of file xfs_alloc.c. Caller 0xc01a04ed Mar 22 02:27:49 fs5-12 kernel: ccda9944 c019f70d c02f1cca 00000001 00000000 c02f1cbe 00000127 c01a04ed Mar 22 02:27:49 fs5-12 kernel: 00000000 00000000 00000000 00000001 dad40f70 dad40eec 000039d3 c01a04ed Mar 22 02:27:49 fs5-12 kernel: dad40f70 dad40eec 000039d3 00000007 000039d9 00000001 00000001 000041b4 Mar 22 02:27:49 fs5-12 kernel: Call Trace: [] [] [] [] [] Mar 22 02:27:49 fs5-12 kernel: [] [] [] [] [] [] Mar 22 02:27:49 fs5-12 kernel: [] [] [] [] [] [] Mar 22 02:27:49 fs5-12 kernel: [] [] [] [] [] [] Mar 22 02:27:49 fs5-12 kernel: [] [] [] [] [] [] Mar 22 02:27:49 fs5-12 kernel: [] [] [] [] Mar 22 02:27:49 fs5-12 kernel: xfs_force_shutdown(sd(8,7),0x8) called from line 1070 of file xfs_trans.c. Return address = 0xc01fe096 Mar 22 02:27:49 fs5-12 kernel: Filesystem "sd(8,7)": Corruption of in-memory data detected. Shutting down filesystem: sd(8,7) Mar 22 02:27:49 fs5-12 kernel: Please umount the filesystem, and rectify the problem(s) Mar 22 02:27:49 fs5-12 kernel: nfsd: non-standard errno: -990 Mar 22 02:36:42 fs5-12 kernel: nfsd: last server has exited Mar 22 02:36:42 fs5-12 kernel: nfsd: unexporting all filesystems Mar 22 02:36:42 fs5-12 kernel: rpciod: active tasks at shutdown?! Mar 22 02:37:40 fs5-12 kernel: XFS mounting filesystem sd(8,7) Mar 22 02:37:41 fs5-12 kernel: Starting XFS recovery on filesystem: sd(8,7) (dev: sd(8,7)) Mar 22 02:37:45 fs5-12 kernel: Ending XFS recovery on filesystem: sd(8,7) (dev: sd(8,7)) Mar 22 03:03:54 fs5-12 kernel: 0x0: 6c 61 6e 67 75 61 67 65 3d 30 2c 75 73 0a 00 00 Mar 22 03:03:54 fs5-12 kernel: Filesystem "sd(8,7)": XFS internal error xfs_da_do_buf(2) at line 2272 of file xfs_da_btree.c. Caller 0xc01bea5e Mar 22 03:03:54 fs5-12 kernel: dd3adbb4 c01be8cb c02f2026 00000001 d64e5800 c02f1f2d 000008e0 c01bea5e Mar 22 03:03:54 fs5-12 kernel: c01bea5e ffffffff 0000000f 00000018 00000000 d64e5800 dd3adc04 00000001 Mar 22 03:03:54 fs5-12 kernel: 00000000 d64e5800 05f6a598 00000000 00000000 00000000 d2676e80 00000001 Mar 22 03:03:54 fs5-12 kernel: Call Trace: [] [] [] [] [] Mar 22 03:03:54 fs5-12 kernel: [] [] [] [] [] [] Mar 22 03:03:54 fs5-12 kernel: [] [] [] [] [] [] Mar 22 03:03:54 fs5-12 kernel: [] [] [] [] [] [] Mar 22 03:03:54 fs5-12 kernel: [] [] [] [] [] [] Mar 22 03:03:54 fs5-12 kernel: nfsd: non-standard errno: -990 [root@fileserver root]# lspci 00:00.0 Host bridge: Intel Corp.: Unknown device 254c (rev 01) 00:00.1 Class ff00: Intel Corp. e7500 [Plumas] DRAM Controller Error Reporting (rev 01) 00:02.0 PCI bridge: Intel Corp. e7500 [Plumas] HI_B Virtual PCI Bridge (F0) (rev 01) 00:02.1 Class ff00: Intel Corp. e7500 [Plumas] HI_B Virtual PCI Bridge (F1) (rev 01) 00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev 42) 00:1f.0 ISA bridge: Intel Corp. 82801CA ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801CA IDE U100 (rev 02) 00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus (rev 02) 01:1c.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 04) 01:1d.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 04) 01:1e.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 04) 01:1f.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 04) 02:01.0 Ethernet controller: Intel Corp. 82545EM Gigabit Ethernet Controller (rev 01) 03:01.0 RAID bus controller: 3ware Inc 3ware 7000-series ATA-RAID (rev 01) 04:03.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 04:04.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 0d) 04:05.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet Controller (rev 02) I tried to run xfs_repair to clean the filesystem, unfortunately it couldn't finish: Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 rebuilding directory inode 806216170 rebuilding directory inode 805641623 rebuilding directory inode 253488352 rebuilding directory inode 1782429002 fatal error -- couldn't map inode 1208851203, err = 22 After xfs_repair failed each time, I can remount it and get it run for few days then it will failed again. [root@fileserver root]# xfs_info /dev/sda6 meta-data=/filesystem1 isize=256 agcount=16, agsize=4457911 blks = sectsz=512 data = bsize=4096 blocks=71326576, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 I saw quite alot of post on XFS internal error on different .c files, but doesn't seem to have a fix for all yet. Please let me know for any information required. Regards, Eric Yu Outblaze Ltd ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 25 03:58:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 03:58:57 -0800 (PST) Received: from vcgwp1.bit-drive.ne.jp (vcgwp1.bit-drive.ne.jp [211.9.32.211]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PBwqKO018950 for ; Thu, 25 Mar 2004 03:58:52 -0800 Received: (qmail 7893 invoked from network); 25 Mar 2004 20:58:50 +0900 Received: from unknown (HELO dns01.miraclelinux.com) (219.118.163.66) by vcgwp1.bit-drive.ne.jp with SMTP; 25 Mar 2004 20:58:50 +0900 Received: from miraclelinux.com (dhcp-0139.miraclelinux.com [10.1.0.139]) by dns01.miraclelinux.com (8.9.3+3.2W/3.7W/03090111) with ESMTP id UAA20948; Thu, 25 Mar 2004 20:58:50 +0900 Message-ID: <4062C97A.6030702@miraclelinux.com> Date: Thu, 25 Mar 2004 20:58:50 +0900 From: "IKARASHI, Seiichi" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: Chris Wedgwood CC: linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> In-Reply-To: <20040325063902.GA9697@dingdong.cryptoapps.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2583 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ikarashi@miraclelinux.com Precedence: bulk X-list: linux-xfs Content-Length: 1132 Lines: 43 Thanks to your follow-up. Chris Wedgwood wrote: >>How do you guys synchronize a XFS partition? > > > sync() > > of xfs_freeze depending on what you want Thanks. I will try xfs_freeze. >>Repeating sync() does not take effect. >>Is there any specific command or operation to sync XFS? > > > sync() should work --- why do you think it does? Because anaconda/booty fails to install grub into a XFS partition. Firstly anaconda executes "grub-install --just-copy", and executes sync() three times. Then anaconda runs "grub --batch" to really install grub into MBR of the disk, but grub cannot find files which should have been already written in the partition by sync(). grub does not try to seek those files through filesystem, but reads the volume directly by its internal functions like xfs_dir(). When I put 1 minutes of sleep() next to sync(), grub finds those files and is installed successfully. That's why I think a XFS partition needa much time to synchronize. > what kernel version are you using? I'm using a kernel based on RHEL3.0 U1 (2.4.21-9.EL.i686) applied XFS 1.3.1 patch from http://www.oss.sgi.com/. From owner-linux-xfs@oss.sgi.com Thu Mar 25 04:15:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 04:15:35 -0800 (PST) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PCF7KO020142 for ; Thu, 25 Mar 2004 04:15:09 -0800 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i2PCEtId020823; Thu, 25 Mar 2004 13:14:55 +0100 Message-ID: <4062CD3E.5070200@stesmi.com> Date: Thu, 25 Mar 2004 13:14:54 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "IKARASHI, Seiichi" CC: Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> In-Reply-To: <4062C97A.6030702@miraclelinux.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2584 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 826 Lines: 23 Hi. >>sync() should work --- why do you think it does? > > Because anaconda/booty fails to install grub into a XFS partition. > > Firstly anaconda executes "grub-install --just-copy", and > executes sync() three times. Then anaconda runs "grub --batch" > to really install grub into MBR of the disk, > but grub cannot find files which should have been already > written in the partition by sync(). grub does not try to seek > those files through filesystem, but reads the volume directly > by its internal functions like xfs_dir(). > > When I put 1 minutes of sleep() next to sync(), > grub finds those files and is installed successfully. > That's why I think a XFS partition needa much time to synchronize. That's basically luck I'd say. a 5 minute delay there didn't show any changes for me on some boxen. // Stefan From owner-linux-xfs@oss.sgi.com Thu Mar 25 04:41:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 04:42:02 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PCfuKO024346 for ; Thu, 25 Mar 2004 04:41:58 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id AEA2EFB839; Thu, 25 Mar 2004 06:41:52 -0600 (CST) Date: Thu, 25 Mar 2004 04:41:52 -0800 From: Chris Wedgwood To: "IKARASHI, Seiichi" Cc: linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS Message-ID: <20040325124152.GA12078@dingdong.cryptoapps.com> References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4062C97A.6030702@miraclelinux.com> Content-Transfer-Encoding: 8bit X-archive-position: 2585 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 1278 Lines: 38 On Thu, Mar 25, 2004 at 08:58:50PM +0900, IKARASHI, Seiichi wrote: > I will try xfs_freeze Don't bother. It won't help for what you want. I suggested it becuase it wasn't clear at the time what you were doing. > Because anaconda/booty fails to install grub into a XFS partition. Why does this mean XFS takes a long time to sync then? > Firstly anaconda executes "grub-install --just-copy", and executes > sync() three times. grub is braindead then. Calling sync() once should suffice. > Then anaconda runs "grub --batch" to really install grub into MBR of > the disk, but grub cannot find files which should have been already > written in the partition by sync(). That sounds like something else. sync() ensures dirty buffers are on-disk. Even if you don't sync() you can still read-back using the buffer-cache/page-cache. > When I put 1 minutes of sleep() next to sync(), grub finds those > files and is installed successfully. I'm not sure I follow, but I'n not convinced it's XFS failing to sync() to disk unless it's a really old tree. > I'm using a kernel based on RHEL3.0 U1 (2.4.21-9.EL.i686) applied > XFS 1.3.1 patch from http://www.oss.sgi.com/. Hmm.... I think that should be OK. Have you tried CVS from oss.sgi.com to see if that is any better? From owner-linux-xfs@oss.sgi.com Thu Mar 25 04:46:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 04:46:29 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PCkQKO024822 for ; Thu, 25 Mar 2004 04:46:27 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id BEBD8FB839; Thu, 25 Mar 2004 06:46:25 -0600 (CST) Date: Thu, 25 Mar 2004 04:46:25 -0800 From: Chris Wedgwood To: Greg Koch Cc: linux-xfs@oss.sgi.com Subject: Re: losing disk space Message-ID: <20040325124625.GB12078@dingdong.cryptoapps.com> References: <20040325014100.0aaedcea.gkoch@tampabay.rr.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040325014100.0aaedcea.gkoch@tampabay.rr.com> Content-Transfer-Encoding: 8bit X-archive-position: 2586 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 900 Lines: 24 On Thu, Mar 25, 2004 at 01:41:00AM -0500, Greg Koch wrote: > The last time the disk filled up, I restarted and used xfs-repair > which recovered a bunch of apache logs among other stuff. The disk > has plenty of room now and on most days seems to recover disk space > after the log rotation. Then on some days you dont see any space > recovery. If you remount and allow log-replay to you get the free-space back? Or is it necessary to run xfs_repair to see this? > Gentoo kernel Linux 2.4.25_pre7-gss-r2 NEVER USE GENTOO. Immature Hacks + Bugs == Gentoo. Please get a real kernel from oss.sgi.comand see if that helps. Better still, RUN, don't walk, and get Red Hat or Debian installer. > WDC WD200BB-00CAA1 hard drive in udma5 mode WriteCache=enabled FWIW WriteCache=enabled is probably not advisable (it means the disk can reorder writes and there is a greater chance of corruption). From owner-linux-xfs@oss.sgi.com Thu Mar 25 04:47:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 04:47:56 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PClqKO025421 for ; Thu, 25 Mar 2004 04:47:52 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 6D08FFB83A; Thu, 25 Mar 2004 06:47:51 -0600 (CST) Date: Thu, 25 Mar 2004 04:47:51 -0800 From: Chris Wedgwood To: "IKARASHI, Seiichi" Cc: linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS Message-ID: <20040325124751.GC12078@dingdong.cryptoapps.com> References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> <20040325124152.GA12078@dingdong.cryptoapps.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040325124152.GA12078@dingdong.cryptoapps.com> Content-Transfer-Encoding: 8bit X-archive-position: 2587 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 470 Lines: 15 On Thu, Mar 25, 2004 at 04:41:52AM -0800, Chris Wedgwood wrote: > That sounds like something else. sync() ensures dirty buffers are > on-disk. Even if you don't sync() you can still read-back using the > buffer-cache/page-cache. OK, I understand now. Calling sync() multuple times is still baindead. How about umount/mount and see if that forces the data to appear? If so, please try a newer kernel as the sync paths were rewritten and might fix your problem. From owner-linux-xfs@oss.sgi.com Thu Mar 25 05:00:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 05:00:32 -0800 (PST) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PD0RKO026122 for ; Thu, 25 Mar 2004 05:00:28 -0800 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i2PD0MId022617; Thu, 25 Mar 2004 14:00:22 +0100 Message-ID: <4062D7E5.6070501@stesmi.com> Date: Thu, 25 Mar 2004 14:00:21 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wedgwood CC: "IKARASHI, Seiichi" , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> <20040325124152.GA12078@dingdong.cryptoapps.com> In-Reply-To: <20040325124152.GA12078@dingdong.cryptoapps.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2588 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 1356 Lines: 39 Hi. >>Firstly anaconda executes "grub-install --just-copy", and executes >>sync() three times. > > grub is braindead then. Calling sync() once should suffice. Grub does it as a workaround. >>Then anaconda runs "grub --batch" to really install grub into MBR of >>the disk, but grub cannot find files which should have been already >>written in the partition by sync(). > > That sounds like something else. sync() ensures dirty buffers are > on-disk. Even if you don't sync() you can still read-back using the > buffer-cache/page-cache. Or.. Should. >>When I put 1 minutes of sleep() next to sync(), grub finds those >>files and is installed successfully. > > I'm not sure I follow, but I'n not convinced it's XFS failing to > sync() to disk unless it's a really old tree. Happens with current tree I can tell you that me and .. Steve I think discussed it on IRC a while back and he looked into the POSIX spec and according to POSIX a filesystem does not have to keep the block device the same as the filesystem after a sync() (or mounting SYNC). In the case of XFS it _should_ but doesn't but it's not violating any specs. And Grub relies on the filesystem keeping the block device in sync with the filesystem after a sync() call. That's a bug in both Grub and XFS but XFS isn't the one violating the spec, even though it's a bug. // Stefan From owner-linux-xfs@oss.sgi.com Thu Mar 25 05:22:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 05:22:04 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PDM0KO027280 for ; Thu, 25 Mar 2004 05:22:01 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 1FF02FB839; Thu, 25 Mar 2004 07:22:00 -0600 (CST) Date: Thu, 25 Mar 2004 05:22:00 -0800 From: Chris Wedgwood To: Stefan Smietanowski Cc: "IKARASHI, Seiichi" , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS Message-ID: <20040325132200.GA12333@dingdong.cryptoapps.com> References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> <20040325124152.GA12078@dingdong.cryptoapps.com> <4062D7E5.6070501@stesmi.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4062D7E5.6070501@stesmi.com> Content-Transfer-Encoding: 8bit X-archive-position: 2589 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 1238 Lines: 31 On Thu, Mar 25, 2004 at 02:00:21PM +0100, Stefan Smietanowski wrote: > Grub does it as a workaround. It's stupid. How does sync() multiple times in secession work better than once? > Happens with current tree I can tell you that me and .. Steve I > think discussed it on IRC a while back and he looked into the POSIX > spec and according to POSIX a filesystem does not have to keep the > block device the same as the filesystem after a sync() (or mounting > SYNC). Well, not to split hair, sync() means all data needs to hit the disk. Accessing it via a bock device for a mounted filesystem will cause bad stuff --- is this what grub does? I umount/mount should enforce everything is written an consistent. Grub could also use O_DIRECT if it didn't trust direct-block access was going to be in sync. with the fs after a sync() call (which as you say strictly speaking it need not be). > And Grub relies on the filesystem keeping the block device in sync > with the filesystem after a sync() call. That's a bug in both Grub > and XFS but XFS isn't the one violating the spec, even though it's a > bug. If the filesystem is mounted, grub is doing something it can't rely on. Grub could use O_DIRECT probably to work around this. From owner-linux-xfs@oss.sgi.com Thu Mar 25 05:27:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 05:27:11 -0800 (PST) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PDR5KO027840 for ; Thu, 25 Mar 2004 05:27:08 -0800 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i2PDR0Id023728; Thu, 25 Mar 2004 14:27:00 +0100 Message-ID: <4062DE23.9020604@stesmi.com> Date: Thu, 25 Mar 2004 14:26:59 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wedgwood CC: "IKARASHI, Seiichi" , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> <20040325124152.GA12078@dingdong.cryptoapps.com> <4062D7E5.6070501@stesmi.com> <20040325132200.GA12333@dingdong.cryptoapps.com> In-Reply-To: <20040325132200.GA12333@dingdong.cryptoapps.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2590 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 1609 Lines: 46 Hi. >>Grub does it as a workaround. > > It's stupid. How does sync() multiple times in secession work better > than once? I never claimed it was smart :) >>Happens with current tree I can tell you that me and .. Steve I >>think discussed it on IRC a while back and he looked into the POSIX >>spec and according to POSIX a filesystem does not have to keep the >>block device the same as the filesystem after a sync() (or mounting >>SYNC). > > Well, not to split hair, sync() means all data needs to hit the disk. > Accessing it via a bock device for a mounted filesystem will cause bad > stuff --- is this what grub does? Yup. > I umount/mount should enforce everything is written an consistent. It does, but you can't unmount and then mount the filesystem if you don't have a seperate /boot partition. > Grub could also use O_DIRECT if it didn't trust direct-block access > was going to be in sync. with the fs after a sync() call (which as you > say strictly speaking it need not be). Yup. I'd need to check up if O_DIRECT is supported in the XFS I run. >>And Grub relies on the filesystem keeping the block device in sync >>with the filesystem after a sync() call. That's a bug in both Grub >>and XFS but XFS isn't the one violating the spec, even though it's a >>bug. > > If the filesystem is mounted, grub is doing something it can't rely > on. Grub could use O_DIRECT probably to work around this. Yup. My sentiments exactly. I'll have a look into it and see if I can't get it to work that way - at least it would work for a few more cases (those where O_DIRECT is supported). // Stefan From owner-linux-xfs@oss.sgi.com Thu Mar 25 05:42:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 05:42:43 -0800 (PST) Received: from relay03.roc.ny.frontiernet.net (relay03.roc.ny.frontiernet.net [66.133.131.36]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PDgdKO028922 for ; Thu, 25 Mar 2004 05:42:40 -0800 Received: (qmail 906 invoked from network); 25 Mar 2004 13:42:38 -0000 Received: from unknown (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay03.roc.ny.frontiernet.net (FrontierMTA 2.3.7c) with SMTP for ; 25 Mar 2004 13:42:38 -0000 Message-ID: <4062E19A.90207@xfs.org> Date: Thu, 25 Mar 2004 07:41:46 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wedgwood CC: Stefan Smietanowski , "IKARASHI, Seiichi" , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> <20040325124152.GA12078@dingdong.cryptoapps.com> <4062D7E5.6070501@stesmi.com> <20040325132200.GA12333@dingdong.cryptoapps.com> In-Reply-To: <20040325132200.GA12333@dingdong.cryptoapps.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2591 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1515 Lines: 45 Chris Wedgwood wrote: > On Thu, Mar 25, 2004 at 02:00:21PM +0100, Stefan Smietanowski wrote: > > >>Grub does it as a workaround. > > > It's stupid. How does sync() multiple times in secession work better > than once? > > >>Happens with current tree I can tell you that me and .. Steve I >>think discussed it on IRC a while back and he looked into the POSIX >>spec and according to POSIX a filesystem does not have to keep the >>block device the same as the filesystem after a sync() (or mounting >>SYNC). > > > Well, not to split hair, sync() means all data needs to hit the disk. > Accessing it via a bock device for a mounted filesystem will cause bad > stuff --- is this what grub does? > sync means the filesystem will look the same after a crash, it does not mean all the data has to hit the disk. In the case of XFS it does not really mean this. Sync will make sure that the journal is upto date on disk, so the metadata can be recovered after a crash. Making sync push all the metadata itself would slow it down. Now if grub is opening the block device and reading out of that, it is looking at the same pages for metadata that xfs is looking at in memory. There is a bug where you can get corruption if you access the block device in parallel with the filesystem. Possibly this is behind the problem. Christoph has been looking into fixing this. Does grub just read from the block device, or does it do writes too? Writes directly in via the block device could really confuse things. Steve From owner-linux-xfs@oss.sgi.com Thu Mar 25 06:07:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 06:07:30 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PE7OKO029901 for ; Thu, 25 Mar 2004 06:07:25 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id A8ADCFB839; Thu, 25 Mar 2004 08:07:23 -0600 (CST) Date: Thu, 25 Mar 2004 06:07:23 -0800 From: Chris Wedgwood To: Steve Lord Cc: Stefan Smietanowski , "IKARASHI, Seiichi" , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS Message-ID: <20040325140723.GA12558@dingdong.cryptoapps.com> References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> <20040325124152.GA12078@dingdong.cryptoapps.com> <4062D7E5.6070501@stesmi.com> <20040325132200.GA12333@dingdong.cryptoapps.com> <4062E19A.90207@xfs.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4062E19A.90207@xfs.org> Content-Transfer-Encoding: 8bit X-archive-position: 2592 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 1788 Lines: 46 On Thu, Mar 25, 2004 at 07:41:46AM -0600, Steve Lord wrote: > sync means the filesystem will look the same after a crash, it does > not mean all the data has to hit the disk. In the case of XFS it > does not really mean this. Sync will make sure that the journal is > upto date on disk, so the metadata can be recovered after a > crash. fsync()/sync() should mean all dirty DATA blocks and METADATA blocks are flushed to the backing store. Anything less than this is a bug. SuS requires that sync() schedule writes to the file system but not necessarily complete before the system call returns --- however, Linux has for some time actually had the system call block during write-out (very early version on Linux didn't do this). http://www.opengroup.org/onlinepubs/007904975/functions/sync.html > Making sync push all the metadata itself would slow it down. sync() should also flush the metadata. If people wish to only flush data blocks there is fdatasync() for smart applications. Applications such as MTAs and some databases *depend* on these characteristics. Now, since you wrote the new sync' code I'm not going to argue at to what XFS does, but as far as I can tell sync() does indeed flush all datablocks to disk. Because metadata is isn't backed buthe buffer cache I guess that doesn't get flushed? But it idally it should :-) > Now if grub is opening the block device and reading out of that, it > is looking at the same pages for metadata that xfs is looking at in > memory. There is a bug where you can get corruption if you access > the block device in parallel with the filesystem. Possibly this is > behind the problem. This will cause an oops on 2.6.x won't it --- so I suspect if this is behind the problem the report will be have been different. --cw From owner-linux-xfs@oss.sgi.com Thu Mar 25 06:45:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 06:45:32 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PEjRKO031257 for ; Thu, 25 Mar 2004 06:45:28 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1B6W6h-0006Ba-K9; Thu, 25 Mar 2004 14:45:19 +0000 Date: Thu, 25 Mar 2004 14:45:19 +0000 From: Christoph Hellwig To: Chris Wedgwood Cc: Steve Lord , Stefan Smietanowski , "IKARASHI, Seiichi" , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS Message-ID: <20040325144519.A23764@infradead.org> References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> <20040325124152.GA12078@dingdong.cryptoapps.com> <4062D7E5.6070501@stesmi.com> <20040325132200.GA12333@dingdong.cryptoapps.com> <4062E19A.90207@xfs.org> <20040325140723.GA12558@dingdong.cryptoapps.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040325140723.GA12558@dingdong.cryptoapps.com>; from cw@f00f.org on Thu, Mar 25, 2004 at 06:07:23AM -0800 Content-Transfer-Encoding: 8bit X-archive-position: 2593 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 1247 Lines: 28 On Thu, Mar 25, 2004 at 06:07:23AM -0800, Chris Wedgwood wrote: > fsync()/sync() should mean all dirty DATA blocks and METADATA blocks > are flushed to the backing store. Anything less than this is a bug. Depends on how you define backing store. > > > Making sync push all the metadata itself would slow it down. > > sync() should also flush the metadata. If people wish to only flush > data blocks there is fdatasync() for smart applications. Read again what Steve wrote. All metadata is in the log, so it's not lost on a crash. It's inplace, though, so unless grub relays the log in memory somewhere before trying to use it's own xfs implementation in userspace (which it doesn't), it doesn't see the data yet. > > Now if grub is opening the block device and reading out of that, it > > is looking at the same pages for metadata that xfs is looking at in > > memory. There is a bug where you can get corruption if you access > > the block device in parallel with the filesystem. Possibly this is > > behind the problem. > > This will cause an oops on 2.6.x won't it --- so I suspect if this is > behind the problem the report will be have been different. I don't think they're hitting the problem, the symptoms look very different. From owner-linux-xfs@oss.sgi.com Thu Mar 25 07:32:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 07:33:00 -0800 (PST) Received: from redix.it (host49-169.pool8172.interbusiness.it [81.72.169.49]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PFWtKO000427 for ; Thu, 25 Mar 2004 07:32:56 -0800 Received: (qmail 15889 invoked by uid 72); 25 Mar 2004 15:32:53 -0000 Received: from 81.72.169.49 (SquirrelMail authenticated user roberto) by mail.redix.it with HTTP; Thu, 25 Mar 2004 16:32:52 +0100 (CET) Message-ID: <44293.81.72.169.49.1080228772.squirrel@mail.redix.it> In-Reply-To: <20040325014100.0aaedcea.gkoch@tampabay.rr.com> References: <20040325014100.0aaedcea.gkoch@tampabay.rr.com> Date: Thu, 25 Mar 2004 16:32:52 +0100 (CET) Subject: Re: losing disk space From: roberto@redix.it To: "Greg Koch" Cc: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-archive-position: 2594 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roberto@redix.it Precedence: bulk X-list: linux-xfs Content-Length: 1543 Lines: 43 > I have a server running apache on an 18GB xfs partition. It seems to > loose large chunks of disk space around the time the apache logs rotate. > The apache logs get to be around 2 gig at the end of the day and are > compressed and started over by logrotate. df reports one value > while du-sch / reports another. The value du give stays pretty much > steady while the value df gives shows a gradual loss of disk space. > > The last time the disk filled up, I restarted and used xfs-repair which > recovered a bunch of apache logs among other stuff. The disk has plenty > of room now and on most days seems to recover disk space after the log > rotation. Then on some days you dont see any space recovery. > > Here are some other details: > Gentoo kernel Linux 2.4.25_pre7-gss-r2 > Dual Xeon 1.8 GHz CPU > WDC WD200BB-00CAA1 hard drive in udma5 mode WriteCache=enabled > xfsprogs 2.3.9 > logrotate 3.6.5 > syslogd 1.4.1 > apache 2.0.48 > > -- > > My colleagues, every statement I make today is backed up by sources, > solid sources. These are not assertions. What we are giving you are > facts and conclusions based on solid intelligence. > > > Maybe the problem is related to some process(es) that do not close a file descriptor (a previously opened file), and a user or another precess has removed the file. As far I know "df" shows the free space with the "opened" but deleted file, du shows the free space). Please check the log rotation procedure and check the process open file (please man "lsoft" and "fuser"). Bye Roberto From owner-linux-xfs@oss.sgi.com Thu Mar 25 08:33:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 08:33:25 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2PGXNKO005739 for ; Thu, 25 Mar 2004 08:33:23 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2PGXM9B005738 for linux-xfs@oss.sgi.com; Thu, 25 Mar 2004 08:33:22 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2PGXLKO005724 for ; Thu, 25 Mar 2004 08:33:21 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2PFhJse001093; Thu, 25 Mar 2004 07:43:19 -0800 Date: Thu, 25 Mar 2004 07:43:19 -0800 Message-Id: <200403251543.i2PFhJse001093@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 321] XFS internal error, xfs_force_shutdown on 1.2TB fileserver. X-Bugzilla-Reason: AssignedTo X-archive-position: 2595 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 951 Lines: 31 http://oss.sgi.com/bugzilla/show_bug.cgi?id=321 sandeen@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From sandeen@sgi.com 2004-25-03 07:43 PDT ------- The linux 2.4 kernel really can't handle > 1T block devices. You're probably seeing something wrapping around 32 bits and clobbering the filesystem. If you really need > 1T, use 2.6 with CONFIG_LBD enabled. This is a core kernel I/O path issue, not oan xfs issue. See http://www.gelato.unsw.edu.au/IA64wiki/LargeBlockDevices for more information. If you can reproduce this with a filesystem < 1T, please re-open. -Eric ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 25 09:00:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 09:00:23 -0800 (PST) Received: from mailhub-3.iastate.edu (mailhub-3.iastate.edu [129.186.140.13]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PH0JKO006948 for ; Thu, 25 Mar 2004 09:00:19 -0800 Received: from mailout-1.iastate.edu (mailout-1.iastate.edu [129.186.140.1]) by mailhub-3.iastate.edu (8.12.10/8.12.10) with SMTP id i2PH0CEf017103 for ; Thu, 25 Mar 2004 11:00:13 -0600 Received: from pircsds0.agron.iastate.edu(129.186.26.63) by mailout-1.iastate.edu via csmap id 7dfe698a_7e7d_11d8_9927_00304811d932_10473; Thu, 25 Mar 2004 16:57:25 +0000 (UTC) Date: Thu, 25 Mar 2004 11:00:14 -0600 (CST) From: Daryl Herzmann X-X-Sender: akrherz@pircsds0.agron.iastate.edu To: linux-xfs@oss.sgi.com Subject: >1 TB RAID servers Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2596 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akrherz@iastate.edu Precedence: bulk X-list: linux-xfs Content-Length: 969 Lines: 31 Hiya, I am intrigued by the message below by Eric. I have 4 machines running with XFS on kernel 2.4 with software-or-hardware RAID arrays well over 1 TB in size. Have I just been lucky that the filesystems have not been trashed itself yet? Time to hug my backups even tighter!? :) Thanks, Daryl ---------- Forwarded message ---------- ------- Additional Comments From sandeen@sgi.com 2004-25-03 07:43 PDT ------- The linux 2.4 kernel really can't handle > 1T block devices. You're probably seeing something wrapping around 32 bits and clobbering the filesystem. If you really need > 1T, use 2.6 with CONFIG_LBD enabled. This is a core kernel I/O path issue, not oan xfs issue. See http://www.gelato.unsw.edu.au/IA64wiki/LargeBlockDevices for more information. If you can reproduce this with a filesystem < 1T, please re-open. -Eric ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 25 09:13:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 09:13:53 -0800 (PST) Received: from mailman2.ppco.com (mailman2.ppco.com [138.32.33.140]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PHDZKO007667 for ; Thu, 25 Mar 2004 09:13:36 -0800 Received: from bvlextrd01.conoco.net (trend1.ppco.com [138.32.33.139]) by mailman2.ppco.com (8.12.8/8.12.8) with ESMTP id i2PHDZ8S016019 for ; Thu, 25 Mar 2004 11:13:35 -0600 Received: from mail1.ppco.com ([138.32.31.56]) by bvlextrd01 with trend_isnt_name_B; Thu, 25 Mar 2004 11:18:27 -0600 Received: from bvlexbh1.conoco.net (bvlexbh1.conoco.net [138.32.45.41]) by mail1.ppco.com (8.11.6+Sun/8.11.6) with ESMTP id i2PHDX108567; Thu, 25 Mar 2004 11:13:33 -0600 (CST) Received: from hoexbh2.conoco.net ([144.46.83.12]) by bvlexbh1.conoco.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 25 Mar 2004 11:13:33 -0600 Received: from hoexmb3.conoco.net ([144.46.87.144]) by hoexbh2.conoco.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 25 Mar 2004 11:13:32 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: >1 TB RAID servers Date: Thu, 25 Mar 2004 11:13:32 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: >1 TB RAID servers Thread-Index: AcQSirc6eJZIT5TQTQCh0cyCl0B2oQAAYimw From: "Rivera, Angel R" To: "Daryl Herzmann" , X-OriginalArrivalTime: 25 Mar 2004 17:13:32.0902 (UTC) FILETIME=[8036E860:01C4128C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i2PHDaKO007668 X-archive-position: 2597 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Angel.R.Rivera@conocophillips.com Precedence: bulk X-list: linux-xfs Content-Length: 948 Lines: 30 2.4 kernel should support 2TB. -----Original Message----- From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com]On Behalf Of Daryl Herzmann Sent: Thursday, March 25, 2004 11:00 AM To: linux-xfs@oss.sgi.com Subject: >1 TB RAID servers Hiya, I am intrigued by the message below by Eric. I have 4 machines running with XFS on kernel 2.4 with software-or-hardware RAID arrays well over 1 TB in size. Have I just been lucky that the filesystems have not been trashed itself yet? Time to hug my backups even tighter!? :) Thanks, Daryl ---------- Forwarded message ---------- ------- Additional Comments From sandeen@sgi.com 2004-25-03 07:43 PDT ------- The linux 2.4 kernel really can't handle > 1T block devices. You're probably seeing something wrapping around 32 bits and clobbering the filesystem. If you really need > 1T, use 2.6 with CONFIG_LBD enabled. This is a core kernel I/O path issue, not oan xfs issue. From owner-linux-xfs@oss.sgi.com Thu Mar 25 09:53:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 09:53:48 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PHrkKO009439 for ; Thu, 25 Mar 2004 09:53:46 -0800 Received: from chaos.egr.duke.edu (localhost.localdomain [127.0.0.1]) by chaos.egr.duke.edu (8.12.8/8.12.8) with ESMTP id i2PHrdwc025572; Thu, 25 Mar 2004 12:53:39 -0500 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.12.8/8.12.8/Submit) with ESMTP id i2PHrdaJ025568; Thu, 25 Mar 2004 12:53:39 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Thu, 25 Mar 2004 12:53:39 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Daryl Herzmann cc: linux-xfs@oss.sgi.com Subject: Re: >1 TB RAID servers In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2598 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 755 Lines: 22 On Thu, 25 Mar 2004 at 11:00am, Daryl Herzmann wrote > Hiya, > > I am intrigued by the message below by Eric. I have 4 machines running > with XFS on kernel 2.4 with software-or-hardware RAID arrays well over 1 > TB in size. Have I just been lucky that the filesystems have not been > trashed itself yet? Time to hug my backups even tighter!? :) I was going to add to the bug likewise. I've got two machines with dual 3ware 7508 cards running hardware RAID5 with software RAID0 stripes across the cards. The md stripe ends up just under 2TB. They're currently running 2.4.21 + XFS 1.3. In fact, I know of several folks with arrays limited only by the 2TB limit. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Thu Mar 25 11:23:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 11:23:50 -0800 (PST) Received: from deslab.mit.edu (DESLAB.MIT.EDU [18.38.0.40]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PJNhKO018540 for ; Thu, 25 Mar 2004 11:23:43 -0800 Received: from deslab.mit.edu (localhost [127.0.0.1]) by deslab.mit.edu (8.12.9-20030917/8.12.9) with ESMTP id i2PJNgg1025501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 25 Mar 2004 14:23:43 -0500 Received: (from baker@localhost) by deslab.mit.edu (8.12.9-20030917/8.12.9/Submit) id i2PJNg1Z025499 for linux-xfs@oss.sgi.com; Thu, 25 Mar 2004 14:23:42 -0500 Date: Thu, 25 Mar 2004 14:23:42 -0500 From: "F. Baker" Message-Id: <200403251923.i2PJNg1Z025499@deslab.mit.edu> To: linux-xfs@oss.sgi.com Subject: nfs problems w/xfs filesystems X-archive-position: 2599 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: baker@deslab.mit.edu Precedence: bulk X-list: linux-xfs Content-Length: 983 Lines: 30 We have several Linux x86 workstations here. In "dmesg" on these PCs I see a lot of errors that read: NFS: Server wrote less than requested. AND eth0: TX underrun, threshold adjusted. This message appears whenever someone logged into the Mandrake/RH/whatever box (with NFS autofs mounting in his/her home directory) tries to write something to an nfs-mounted directory (usually the home directory). Even small files of 1.5 MB or so often generate something such as "I/O error" when saving a file (really small files usually get saved fine). And the home directory is always based in an SGI (O2, Indy, Onyx) with xfs file system. Intra-SGI these transfer take place perfectly, but Mandrake/RH/OtherLinux generates these problems. Has anyone seen this error before and does anyone know how to get around it? The kernel used is 2.4.22-28 for most of the Mandrake boxes, or at least 2.4.x anyway. We have not gone to 2.6.x yet. Thanks in advance. baker@deslab.mit.edu From owner-linux-xfs@oss.sgi.com Thu Mar 25 13:27:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 13:27:58 -0800 (PST) Received: from relay03.roc.ny.frontiernet.net (relay03.roc.ny.frontiernet.net [66.133.131.36]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PLRpKO028848 for ; Thu, 25 Mar 2004 13:27:53 -0800 Received: (qmail 2539 invoked from network); 25 Mar 2004 21:27:50 -0000 Received: from 208-186-10-249.nrp1.brv.mn.frontiernet.net (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay03.roc.ny.frontiernet.net (FrontierMTA 2.3.18) with SMTP for ; 25 Mar 2004 21:27:50 -0000 Message-ID: <40634EA3.3080302@xfs.org> Date: Thu, 25 Mar 2004 15:26:59 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joshua Baker-LePain CC: Daryl Herzmann , linux-xfs@oss.sgi.com Subject: Re: >1 TB RAID servers References: In-Reply-To: Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2600 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 944 Lines: 28 Joshua Baker-LePain wrote: > On Thu, 25 Mar 2004 at 11:00am, Daryl Herzmann wrote > > >>Hiya, >> >>I am intrigued by the message below by Eric. I have 4 machines running >>with XFS on kernel 2.4 with software-or-hardware RAID arrays well over 1 >>TB in size. Have I just been lucky that the filesystems have not been >>trashed itself yet? Time to hug my backups even tighter!? :) > > > I was going to add to the bug likewise. I've got two machines with dual > 3ware 7508 cards running hardware RAID5 with software RAID0 stripes across > the cards. The md stripe ends up just under 2TB. They're currently > running 2.4.21 + XFS 1.3. > > In fact, I know of several folks with arrays limited only by the 2TB > limit. > But maybe you are lucky in using drivers which are clean in the right places, for example incorrect use of a signed var can mess this up. Some drivers do not work so well when you go out beyond 1 Tbyte. Steve From owner-linux-xfs@oss.sgi.com Thu Mar 25 13:34:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 13:35:01 -0800 (PST) Received: from rrzd1.rz.uni-regensburg.de (rrzd1.rz.uni-regensburg.de [132.199.1.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PLYtKO029381 for ; Thu, 25 Mar 2004 13:34:56 -0800 Received: from rrzd1 (rrzd1 [127.0.0.1]) by rrzd1.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with ESMTP id i2PLYftW017976; Thu, 25 Mar 2004 22:34:42 +0100 Received: from rx3227.cip.uni-regensburg.de ([132.199.237.32]) by rrzd1 (MailMonitor for SMTP v1.2.2 ) ; Thu, 25 Mar 2004 22:34:41 +0100 (CET) Subject: Re: >1 TB RAID servers From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: Steve Lord , hch@infradead.org Cc: Joshua Baker-LePain , Daryl Herzmann , linux-xfs@oss.sgi.com In-Reply-To: <40634EA3.3080302@xfs.org> References: <40634EA3.3080302@xfs.org> Content-type: text/plain Message-Id: <1080250482.1563.8.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 25 Mar 2004 22:34:42 +0100 Content-Transfer-Encoding: 8bit X-archive-position: 2601 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 1210 Lines: 38 On Thu, 2004-03-25 at 22:26, Steve Lord wrote: > Joshua Baker-LePain wrote: > > On Thu, 25 Mar 2004 at 11:00am, Daryl Herzmann wrote > > > > > >>Hiya, > >> > >>I am intrigued by the message below by Eric. I have 4 machines running > >>with XFS on kernel 2.4 with software-or-hardware RAID arrays well over 1 > >>TB in size. Have I just been lucky that the filesystems have not been > >>trashed itself yet? Time to hug my backups even tighter!? :) > > > > > > I was going to add to the bug likewise. I've got two machines with dual > > 3ware 7508 cards running hardware RAID5 with software RAID0 stripes across > > the cards. The md stripe ends up just under 2TB. They're currently > > running 2.4.21 + XFS 1.3. > > > > In fact, I know of several folks with arrays limited only by the 2TB > > limit. > > > > But maybe you are lucky in using drivers which are clean in > the right places, for example incorrect use of a signed var > can mess this up. Some drivers do not work so well when you go out > beyond 1 Tbyte. > Thanks, Steve. By the way: which drivers are supposed to be save in 2.4? Christoph, you're doing some work on the scsi front, could you enlight us? cheers. - Christian From owner-linux-xfs@oss.sgi.com Thu Mar 25 13:39:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 13:39:59 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PLduKO029869 for ; Thu, 25 Mar 2004 13:39:57 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1B6cZr-0007XD-BH; Thu, 25 Mar 2004 21:39:51 +0000 Date: Thu, 25 Mar 2004 21:39:51 +0000 From: Christoph Hellwig To: Christian Guggenberger Cc: Steve Lord , Joshua Baker-LePain , Daryl Herzmann , linux-xfs@oss.sgi.com Subject: Re: >1 TB RAID servers Message-ID: <20040325213951.A28961@infradead.org> References: <40634EA3.3080302@xfs.org> <1080250482.1563.8.camel@bonnie79> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1080250482.1563.8.camel@bonnie79>; from christian.guggenberger@physik.uni-regensburg.de on Thu, Mar 25, 2004 at 10:34:42PM +0100 Content-Transfer-Encoding: 8bit X-archive-position: 2602 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 555 Lines: 15 On Thu, Mar 25, 2004 at 10:34:42PM +0100, Christian Guggenberger wrote: > > But maybe you are lucky in using drivers which are clean in > > the right places, for example incorrect use of a signed var > > can mess this up. Some drivers do not work so well when you go out > > beyond 1 Tbyte. > > > Thanks, Steve. > > By the way: which drivers are supposed to be save in 2.4? > Christoph, you're doing some work on the scsi front, could you enlight > us? No idea, I'm only doing 2.6 scsi work. In general I wouldn't recommend using 2.4 for > 1TB ever. From owner-linux-xfs@oss.sgi.com Thu Mar 25 13:45:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 13:45:12 -0800 (PST) Received: from relay03.roc.ny.frontiernet.net (relay03.roc.ny.frontiernet.net [66.133.131.36]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PLj8KO030412 for ; Thu, 25 Mar 2004 13:45:08 -0800 Received: (qmail 12126 invoked from network); 25 Mar 2004 21:45:04 -0000 Received: from 208-186-10-249.nrp1.brv.mn.frontiernet.net (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay03.roc.ny.frontiernet.net (FrontierMTA 2.3.18) with SMTP for ; 25 Mar 2004 21:45:04 -0000 Message-ID: <406352AD.3050507@xfs.org> Date: Thu, 25 Mar 2004 15:44:13 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: christian.guggenberger@physik.uni-regensburg.de CC: hch@infradead.org, Joshua Baker-LePain , Daryl Herzmann , linux-xfs@oss.sgi.com Subject: Re: >1 TB RAID servers References: <40634EA3.3080302@xfs.org> <1080250482.1563.8.camel@bonnie79> In-Reply-To: <1080250482.1563.8.camel@bonnie79> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2603 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1517 Lines: 48 Christian Guggenberger wrote: > On Thu, 2004-03-25 at 22:26, Steve Lord wrote: > >>Joshua Baker-LePain wrote: >> >>>On Thu, 25 Mar 2004 at 11:00am, Daryl Herzmann wrote >>> >>> >>> >>>>Hiya, >>>> >>>>I am intrigued by the message below by Eric. I have 4 machines running >>>>with XFS on kernel 2.4 with software-or-hardware RAID arrays well over 1 >>>>TB in size. Have I just been lucky that the filesystems have not been >>>>trashed itself yet? Time to hug my backups even tighter!? :) >>> >>> >>>I was going to add to the bug likewise. I've got two machines with dual >>>3ware 7508 cards running hardware RAID5 with software RAID0 stripes across >>>the cards. The md stripe ends up just under 2TB. They're currently >>>running 2.4.21 + XFS 1.3. >>> >>>In fact, I know of several folks with arrays limited only by the 2TB >>>limit. >>> >> >>But maybe you are lucky in using drivers which are clean in >>the right places, for example incorrect use of a signed var >>can mess this up. Some drivers do not work so well when you go out >>beyond 1 Tbyte. >> > > Thanks, Steve. > > By the way: which drivers are supposed to be save in 2.4? > Christoph, you're doing some work on the scsi front, could you enlight > us? > Not sure which are supposed to be safe, all you can do is ask around as to what hardware/software folks are successfully using with 2.4 for filesystems greater than 1Tbyte. As you can see from Christoph's answer, 2.6 with the large block device option is the preferred option. Steve From owner-linux-xfs@oss.sgi.com Thu Mar 25 13:45:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 13:45:45 -0800 (PST) Received: from localhost.localdomain ([66.45.103.236]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PLjdKO030550 for ; Thu, 25 Mar 2004 13:45:39 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i2PLj5rv007089; Thu, 25 Mar 2004 15:45:06 -0600 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i2PLj4Vf007085; Thu, 25 Mar 2004 15:45:04 -0600 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: Re: >1 TB RAID servers From: Austin Gonyou To: Christoph Hellwig Cc: Christian Guggenberger , Steve Lord , Joshua Baker-LePain , Daryl Herzmann , XFS List In-Reply-To: <20040325213951.A28961@infradead.org> References: <20040325213951.A28961@infradead.org> Content-type: text/plain Content-Transfer-Encoding: 8bit Organization: Coremetrics, Inc. Message-Id: <1080251104.5480.23.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 25 Mar 2004 15:45:04 -0600 X-archive-position: 2604 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 972 Lines: 27 We still use that old 2.4.19 stuff on volumes that are 1.5T max. Going to about 1.7T we notice issues for sure, mainly in the properly reported size. it might show up as 300M, or 1T. 1.5 is the max we've been able to get away with and not have issues of that nature. On Thu, 2004-03-25 at 15:39, Christoph Hellwig wrote: > On Thu, Mar 25, 2004 at 10:34:42PM +0100, Christian Guggenberger > wrote: > > > But maybe you are lucky in using drivers which are clean in > > > the right places, for example incorrect use of a signed var > > > can mess this up. Some drivers do not work so well when you go out > > > beyond 1 Tbyte. > > > > > Thanks, Steve. > > > > By the way: which drivers are supposed to be save in 2.4? > > Christoph, you're doing some work on the scsi front, could you > enlight > > us? > > No idea, I'm only doing 2.6 scsi work. In general I wouldn't > recommend > using 2.4 for > 1TB ever. -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Thu Mar 25 13:53:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 13:53:06 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PLqxKO031380 for ; Thu, 25 Mar 2004 13:53:00 -0800 Received: from chaos.egr.duke.edu (localhost.localdomain [127.0.0.1]) by chaos.egr.duke.edu (8.12.8/8.12.8) with ESMTP id i2PLqewc026319; Thu, 25 Mar 2004 16:52:40 -0500 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.12.8/8.12.8/Submit) with ESMTP id i2PLqe7b026315; Thu, 25 Mar 2004 16:52:40 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Thu, 25 Mar 2004 16:52:40 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Austin Gonyou cc: Christoph Hellwig , Christian Guggenberger , Steve Lord , Daryl Herzmann , XFS List Subject: Re: >1 TB RAID servers In-Reply-To: <1080251104.5480.23.camel@localhost.localdomain> Message-ID: References: <20040325213951.A28961@infradead.org> <1080251104.5480.23.camel@localhost.localdomain> MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2605 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 1708 Lines: 43 On Thu, 25 Mar 2004 at 3:45pm, Austin Gonyou wrote > We still use that old 2.4.19 stuff on volumes that are 1.5T max. Going > to about 1.7T we notice issues for sure, mainly in the properly reported > size. it might show up as 300M, or 1T. 1.5 is the max we've been able to > get away with and not have issues of that nature. Well, to start a list of "it works" combos: 3ware Storage Controller device driver for Linux v1.02.00.036. 2.4.21 with XFS 1.3 software raid0 [jlb@buckbeak jlb]$ sudo fdisk -l /dev/sda Disk /dev/sda: 255 heads, 63 sectors, 135155 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 323 2594466 83 Linux /dev/sda2 324 584 2096482+ 83 Linux /dev/sda3 585 715 1052257+ 83 Linux /dev/sda4 716 134389 1073736405 fd Linux raid autodetect [jlb@buckbeak jlb]$ df Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda1 2553696 1971992 451984 82% / /dev/sdb1 2553696 35300 2388676 2% /home none 1034408 0 1034408 0% /dev/shm /dev/sda3 1035692 38588 944492 4% /tmp /dev/sda2 2063536 38736 1919976 2% /usr/local /dev/sdb3 1035692 233436 749644 24% /var /dev/md0 2147341312 1140921464 1006419848 54% /emfd As you can see, I had to limit to size of sd?4 a bit to stay under the 2TB limit, but this combo is rock solid, and was with the XFS 1.2 release as well (I ran the RH based kernel then). -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Thu Mar 25 14:04:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 14:05:04 -0800 (PST) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PM4gKO032001 for ; Thu, 25 Mar 2004 14:04:43 -0800 Received: from broadpark.no (8.80-202-249.nextgentel.com [80.202.249.8]) by mail.broadpark.no (Postfix) with ESMTP id 03ADC6B51; Thu, 25 Mar 2004 22:38:48 +0100 (MET) Message-ID: <40635166.6040705@broadpark.no> Date: Thu, 25 Mar 2004 22:38:46 +0100 From: Kjell Randa User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Axel Thimm Cc: linux-xfs@oss.sgi.com, Takeru KOMORIYA , Dan Yocum Subject: Re: Kernel oops in 2.4.22-1.2174.nptl_37.rhfc1.atsmp References: <405E219A.7080607@broadpark.no> <20040325063726.GA23797@neu.nirvana> In-Reply-To: <20040325063726.GA23797@neu.nirvana> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2606 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Kjell.Randa@broadpark.no Precedence: bulk X-list: linux-xfs Content-Length: 7615 Lines: 183 Axel Thimm wrote: >On Mon, Mar 22, 2004 at 12:13:30AM +0100, Kjell Randa wrote: > > >>I have been using XFS for more than two years without any problems, but >>lately I have started to get oops messages during time of heavy I/O >>load. The system survives and seems healty afterwords. This may be >>related to upgrade to the current kernel. >> >> > >What was the kernel running before the upgrade? An atrpms kernel or >something else? > It was an atrpms kernel. I have been ugrading the kernel regulary from the atrmp site for the last half year. > > > >>System is a dual P3 866 MHz on av Via board using 4 Western Digital ide >>disks (2x160 Mb + 2x80GB) connect to a IDE PCI controller from HighPoint >>(Rocket133 with a Silicon Image chip SiI680) >> >>The disks are configured in raid1 (software), lvm and filesystems >>formatted with XFS. >> >>System is running Fedore Core1 with kernel downloaded from >>http://atrpms.physik.fu-berlin.de/dist/fc1/ >> >>This kernel conains the following patches: >> * base kernel sources: Taken from Fedora Core 1 >> * XFS: merged patches found in 1.3.1 >> * i2c-2.8.4 and lm_sensors-2.8.4. You should also get the updated >>userland tools and updated kernel modules. >> * Linux Extended Attributes and ACLs 0.8.65. >> * LVM 1.0.7 (courtesy of Komoriya Takeru) >> * v4l2-api (from http://bytesex.org/v4l/) >> * PlanetCCRMA caps patches: capabilities, drm low latency and others. >> * linux-ntfs 2.1.4c >> * bootsplash >> >>kernet is tainted by the Nividia binary driver. >> >>I am not shure if this is a XFS problems or could be related to some >>other patches (lvm), but not beeing a kernel hacker I hope somebody can >>take take look on the ksymoops output and give their opinion. >> >> > >While the atrpms kernels, both up and smp seem to work very stable, I >had another report about the RH9 kernel and lvm/md. So there seems to >be some problem in that combination. I am copying the lvm patch maintainer. > >Could you test the FC1 kernel? It works fine in RH9 environments. > > > >>ksymoops 2.4.5 on i686 2.4.22-1.2174.nptl_37.rhfc1.atsmp. Options used >> -V (default) >> -k /proc/ksyms (default) >> -l /proc/modules (default) >> -o /lib/modules/2.4.22-1.2174.nptl_37.rhfc1.atsmp/ (default) >> -m /boot/System.map-2.4.22-1.2174.nptl_37.rhfc1.atsmp (default) >> >>Warning: You did not tell me where to find symbol information. I will >>assume that the log matches the kernel and modules that are running >>right now and I'll use the default options above for symbol resolution. >>If the current kernel and/or modules do not match the log, you can get >>more accurate output by telling me the kernel version and where to find >>map, modules, ksyms etc. ksymoops -h explains the options. >> >>Error (expand_objects): cannot stat(/lib/ext3.o) for ext3 >>ksymoops: No such file or directory >>Error (expand_objects): cannot stat(/lib/jbd.o) for jbd >>ksymoops: No such file or directory >>Error (expand_objects): cannot stat(/lib/raid1.o) for raid1 >>ksymoops: No such file or directory >>Error (expand_objects): cannot stat(/lib/lvm-mod.o) for lvm-mod >>ksymoops: No such file or directory >>Warning (compare_maps): ksyms_base symbol dmi_broken_R__ver_dmi_broken >>not found in System.map. Ignoring ksyms_base entry >>Warning (map_ksym_to_module): cannot match loaded module ext3 to a >>unique module object. Trace may not be reliable. >>Mar 21 04:07:16 eagle nmbd[1089]: Got SIGHUP dumping debug info. >>Mar 21 04:46:17 eagle kernel: Unable to handle kernel NULL pointer >>dereference at virtual address 00000006 >>Mar 21 04:46:17 eagle kernel: f0a00b70 >>Mar 21 04:46:17 eagle kernel: *pde = 00000000 >>Mar 21 04:46:17 eagle kernel: Oops: 0000 >>Mar 21 04:46:17 eagle kernel: CPU: 1 >>Mar 21 04:46:17 eagle kernel: EIP: 0060:[] Tainted: P >>Using defaults from ksymoops -t elf32-i386 -a i386 >>Mar 21 04:46:17 eagle kernel: EFLAGS: 00010256 >>Mar 21 04:46:17 eagle kernel: eax: 00000000 ebx: 00000002 ecx: >>c9325dbc edx: ffffffff >>Mar 21 04:46:17 eagle kernel: esi: ec557900 edi: 00000000 ebp: >>00000000 esp: c9325d84 >>Mar 21 04:46:17 eagle kernel: ds: 0068 es: 0068 ss: 0068 >>Mar 21 04:46:17 eagle kernel: Process f-prot (pid: 28833, >>stackpage=c9325000) >>Mar 21 04:46:17 eagle kernel: Stack: df460b14 00000000 00000000 00001000 >>00000001 c9325dc0 c9325dbc d2a01380 >>Mar 21 04:46:17 eagle kernel: ef85b000 00000246 d2a01394 00000002 >>ffffffff ffffffff 00000001 ffffffff >>Mar 21 04:46:17 eagle kernel: ffffffff 00000000 00000000 00000000 >>00000000 00001000 00000002 ec557900 >>Mar 21 04:46:17 eagle kernel: Call Trace: [] >>linvfs_get_block [xfs] 0x37 (0xc9325df0) >>Mar 21 04:46:17 eagle kernel: [] block_read_full_page [kernel] >>0x2b6 (0xc9325e0c) >>Mar 21 04:46:18 eagle kernel: [] do_generic_file_read [kernel] >>0x239 (0xc9325e70) >>Mar 21 04:46:18 eagle kernel: [] linvfs_get_block [xfs] 0x0 >>(0xc9325e78) >>Mar 21 04:46:18 eagle kernel: [] file_read_actor [kernel] 0x0 >>(0xc9325ea0) >>Mar 21 04:46:18 eagle kernel: [] generic_file_new_read >>[kernel] 0xc5 (0xc9325ec0) >>Mar 21 04:46:18 eagle kernel: [] file_read_actor [kernel] 0x0 >>(0xc9325ed0) >>Mar 21 04:46:18 eagle kernel: [] dput [kernel] 0x30 (0xc9325ed8) >>Mar 21 04:46:18 eagle kernel: [] generic_file_read [kernel] >>0x2f (0xc9325f0c) >>Mar 21 04:46:18 eagle kernel: [] xfs_read [xfs] 0x133 (0xc9325f24) >>Mar 21 04:46:18 eagle kernel: [] linvfs_read [xfs] 0x72 >>(0xc9325f64) >>Mar 21 04:46:18 eagle kernel: [] sys_read [kernel] 0x97 >>(0xc9325f94) >>Mar 21 04:46:18 eagle kernel: [] system_call [kernel] 0x33 >>(0xc9325fc0) >>Mar 21 04:46:18 eagle kernel: Code: 0f b7 40 06 66 89 46 0c 8b 44 24 7c >>85 c0 74 2e f7 46 18 11 >> >> >> >>EIP; f0a00b70 <[xfs]linvfs_get_block_core+1c0/270> <===== >> >> >>ecx; c9325dbc <_end+8e63944/3034cbe8> >> >>edx; ffffffff >> >>esi; ec557900 <_end+2c095488/3034cbe8> >> >>esp; c9325d84 <_end+8e6390c/3034cbe8> >> >>Trace; f0a00c57 <[xfs]linvfs_get_block+37/40> >>Trace; c0153f26 >>Trace; c013e179 >>Trace; f0a00c20 <[xfs]linvfs_get_block+0/40> >>Trace; c013e7c0 >>Trace; c013e985 >>Trace; c013e7c0 >>Trace; c0167b20 >>Trace; c013eaaf >>Trace; f0a06e53 <[xfs]xfs_read+133/2f0> >>Trace; f0a015e2 <[xfs]linvfs_read+72/f0> >>Trace; c01504f7 >>Trace; c0109b27 >> >>Code; f0a00b70 <[xfs]linvfs_get_block_core+1c0/270> >>00000000 <_EIP>: >>Code; f0a00b70 <[xfs]linvfs_get_block_core+1c0/270> <===== >> 0: 0f b7 40 06 movzwl 0x6(%eax),%eax <===== >>Code; f0a00b74 <[xfs]linvfs_get_block_core+1c4/270> >> 4: 66 89 46 0c mov %ax,0xc(%esi) >>Code; f0a00b78 <[xfs]linvfs_get_block_core+1c8/270> >> 8: 8b 44 24 7c mov 0x7c(%esp,1),%eax >>Code; f0a00b7c <[xfs]linvfs_get_block_core+1cc/270> >> c: 85 c0 test %eax,%eax >>Code; f0a00b7e <[xfs]linvfs_get_block_core+1ce/270> >> e: 74 2e je 3e <_EIP+0x3e> >>Code; f0a00b80 <[xfs]linvfs_get_block_core+1d0/270> >> 10: f7 46 18 11 00 00 00 testl $0x11,0x18(%esi) >> >> >>3 warnings and 4 errors issued. Results may not be reliable. >> >> >> >> > > > From owner-linux-xfs@oss.sgi.com Thu Mar 25 14:37:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 14:37:47 -0800 (PST) Received: from relay03.roc.ny.frontiernet.net (relay03.roc.ny.frontiernet.net [66.133.131.36]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PMbiKO000838 for ; Thu, 25 Mar 2004 14:37:45 -0800 Received: (qmail 15727 invoked from network); 25 Mar 2004 22:37:44 -0000 Received: from 208-186-10-249.nrp1.brv.mn.frontiernet.net (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay03.roc.ny.frontiernet.net (FrontierMTA 2.3.18) with SMTP for ; 25 Mar 2004 22:37:44 -0000 Message-ID: <40635F04.6010109@xfs.org> Date: Thu, 25 Mar 2004 16:36:52 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: Chris Wedgwood , Stefan Smietanowski , "IKARASHI, Seiichi" , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> <20040325124152.GA12078@dingdong.cryptoapps.com> <4062D7E5.6070501@stesmi.com> <20040325132200.GA12333@dingdong.cryptoapps.com> <4062E19A.90207@xfs.org> <20040325140723.GA12558@dingdong.cryptoapps.com> <20040325144519.A23764@infradead.org> In-Reply-To: <20040325144519.A23764@infradead.org> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2607 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 718 Lines: 24 Christoph Hellwig wrote: > >>>Now if grub is opening the block device and reading out of that, it >>>is looking at the same pages for metadata that xfs is looking at in >>>memory. There is a bug where you can get corruption if you access >>>the block device in parallel with the filesystem. Possibly this is >>>behind the problem. >> >>This will cause an oops on 2.6.x won't it --- so I suspect if this is >>behind the problem the report will be have been different. > > > I don't think they're hitting the problem, the symptoms look very different. > And thinking about it some more, having grub make the filesystem remount readonly would force everything down to disk unlike just doing a sync call. Steve From owner-linux-xfs@oss.sgi.com Thu Mar 25 14:42:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 14:42:11 -0800 (PST) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PMg6KO001357 for ; Thu, 25 Mar 2004 14:42:09 -0800 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i2PMfvId014213; Thu, 25 Mar 2004 23:41:57 +0100 Message-ID: <40636032.3000402@stesmi.com> Date: Thu, 25 Mar 2004 23:41:54 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord CC: Christoph Hellwig , Chris Wedgwood , "IKARASHI, Seiichi" , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> <20040325124152.GA12078@dingdong.cryptoapps.com> <4062D7E5.6070501@stesmi.com> <20040325132200.GA12333@dingdong.cryptoapps.com> <4062E19A.90207@xfs.org> <20040325140723.GA12558@dingdong.cryptoapps.com> <20040325144519.A23764@infradead.org> <40635F04.6010109@xfs.org> In-Reply-To: <40635F04.6010109@xfs.org> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2608 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 852 Lines: 31 Steve Lord wrote: > Christoph Hellwig wrote: > >> >>>> Now if grub is opening the block device and reading out of that, it >>>> is looking at the same pages for metadata that xfs is looking at in >>>> memory. There is a bug where you can get corruption if you access >>>> the block device in parallel with the filesystem. Possibly this is >>>> behind the problem. >>> >>> >>> This will cause an oops on 2.6.x won't it --- so I suspect if this is >>> behind the problem the report will be have been different. >> >> >> >> I don't think they're hitting the problem, the symptoms look very >> different. >> > > And thinking about it some more, having grub make the filesystem remount > readonly would force everything down to disk unlike just doing a sync > call. Tried and failed :( Tried that before but it didn't help unfortunately. // Stefan From owner-linux-xfs@oss.sgi.com Thu Mar 25 14:46:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 14:47:02 -0800 (PST) Received: from relay03.roc.ny.frontiernet.net (relay03.roc.ny.frontiernet.net [66.133.131.36]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PMkwKO001867 for ; Thu, 25 Mar 2004 14:46:59 -0800 Received: (qmail 22039 invoked from network); 25 Mar 2004 22:46:58 -0000 Received: from 208-186-10-249.nrp1.brv.mn.frontiernet.net (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay03.roc.ny.frontiernet.net (FrontierMTA 2.3.18) with SMTP for ; 25 Mar 2004 22:46:58 -0000 Message-ID: <4063612E.4030109@xfs.org> Date: Thu, 25 Mar 2004 16:46:06 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Smietanowski CC: Christoph Hellwig , Chris Wedgwood , "IKARASHI, Seiichi" , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> <20040325124152.GA12078@dingdong.cryptoapps.com> <4062D7E5.6070501@stesmi.com> <20040325132200.GA12333@dingdong.cryptoapps.com> <4062E19A.90207@xfs.org> <20040325140723.GA12558@dingdong.cryptoapps.com> <20040325144519.A23764@infradead.org> <40635F04.6010109@xfs.org> <40636032.3000402@stesmi.com> In-Reply-To: <40636032.3000402@stesmi.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2609 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1228 Lines: 45 Stefan Smietanowski wrote: > Steve Lord wrote: > >> Christoph Hellwig wrote: >> >>> >>>>> Now if grub is opening the block device and reading out of that, it >>>>> is looking at the same pages for metadata that xfs is looking at in >>>>> memory. There is a bug where you can get corruption if you access >>>>> the block device in parallel with the filesystem. Possibly this is >>>>> behind the problem. >>>> >>>> >>>> >>>> This will cause an oops on 2.6.x won't it --- so I suspect if this is >>>> behind the problem the report will be have been different. >>> >>> >>> >>> >>> I don't think they're hitting the problem, the symptoms look very >>> different. >>> >> >> And thinking about it some more, having grub make the filesystem >> remount readonly would force everything down to disk unlike just doing >> a sync >> call. > > > Tried and failed :( > > Tried that before but it didn't help unfortunately. > > // Stefan > So what exactly is the sequence of events here, some files are created in the boot directory via the kernel, then grub wants to look at them via the block device api and its emulation of the filesystem? If we can nail this down, then maybe we can really work out what is going on here. Steve From owner-linux-xfs@oss.sgi.com Thu Mar 25 14:49:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 14:49:34 -0800 (PST) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PMnVKO002396 for ; Thu, 25 Mar 2004 14:49:31 -0800 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i2PMnOId014554; Thu, 25 Mar 2004 23:49:24 +0100 Message-ID: <406361F2.6060308@stesmi.com> Date: Thu, 25 Mar 2004 23:49:22 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord CC: Christoph Hellwig , Chris Wedgwood , "IKARASHI, Seiichi" , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> <20040325124152.GA12078@dingdong.cryptoapps.com> <4062D7E5.6070501@stesmi.com> <20040325132200.GA12333@dingdong.cryptoapps.com> <4062E19A.90207@xfs.org> <20040325140723.GA12558@dingdong.cryptoapps.com> <20040325144519.A23764@infradead.org> <40635F04.6010109@xfs.org> <40636032.3000402@stesmi.com> <4063612E.4030109@xfs.org> In-Reply-To: <4063612E.4030109@xfs.org> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2610 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 1357 Lines: 37 Hi Steve. >>>>>> Now if grub is opening the block device and reading out of that, it >>>>>> is looking at the same pages for metadata that xfs is looking at in >>>>>> memory. There is a bug where you can get corruption if you access >>>>>> the block device in parallel with the filesystem. Possibly this is >>>>>> behind the problem. >>>>> >>>>> This will cause an oops on 2.6.x won't it --- so I suspect if this is >>>>> behind the problem the report will be have been different. >>>> >>>> I don't think they're hitting the problem, the symptoms look very >>>> different. >>> >>> And thinking about it some more, having grub make the filesystem >>> remount readonly would force everything down to disk unlike just >>> doing a sync >>> call. >> >> Tried and failed :( >> >> Tried that before but it didn't help unfortunately. > > So what exactly is the sequence of events here, some files are created > in the boot directory via the kernel, then grub wants to look at them > via the block device api and its emulation of the filesystem? If we > can nail this down, then maybe we can really work out what is going > on here. > > Steve Yup. That's what's happening. It first does one run with --just-copy where it writes the files using the filesystem then reads the same files using the blockdevice and it's own filesystem code basically. // Stefan From owner-linux-xfs@oss.sgi.com Thu Mar 25 15:03:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 15:03:38 -0800 (PST) Received: from relay03.roc.ny.frontiernet.net (relay03.roc.ny.frontiernet.net [66.133.131.36]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PN3RKO003171 for ; Thu, 25 Mar 2004 15:03:28 -0800 Received: (qmail 1516 invoked from network); 25 Mar 2004 23:03:27 -0000 Received: from 208-186-10-249.nrp1.brv.mn.frontiernet.net (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay03.roc.ny.frontiernet.net (FrontierMTA 2.3.18) with SMTP for ; 25 Mar 2004 23:03:27 -0000 Message-ID: <4063650B.20600@xfs.org> Date: Thu, 25 Mar 2004 17:02:35 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Smietanowski CC: Christoph Hellwig , Chris Wedgwood , "IKARASHI, Seiichi" , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> <20040325124152.GA12078@dingdong.cryptoapps.com> <4062D7E5.6070501@stesmi.com> <20040325132200.GA12333@dingdong.cryptoapps.com> <4062E19A.90207@xfs.org> <20040325140723.GA12558@dingdong.cryptoapps.com> <20040325144519.A23764@infradead.org> <40635F04.6010109@xfs.org> <40636032.3000402@stesmi.com> <4063612E.4030109@xfs.org> <406361F2.6060308@stesmi.com> In-Reply-To: <406361F2.6060308@stesmi.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2611 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1020 Lines: 31 Stefan Smietanowski wrote: > > Yup. That's what's happening. It first does one run with --just-copy > where it writes the files using the filesystem then reads the same > files using the blockdevice and it's own filesystem code basically. > > // Stefan > And I presume the files are missing? The bizzare part of this is that if you read the via the block device interface, you are looking at the same in memory pages which xfs uses for the metadata cache. So even if the data has not hit disk yet, things such as names in directories should be visible in the metadata cache. Inodes may be more tricky, since flushing of inodes into the metadata cache is delayed. Try this for an experiment, before the run, set /proc/sys/fs/xfs/sync_interval down to some small number like 1000, pause for a couple of seconds after calling sync, and then see if grub can see the files via the block device. This tunable controls how long xfs delays writing out inodes into the metadata cache from their internal format. Steve From owner-linux-xfs@oss.sgi.com Thu Mar 25 15:06:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 15:06:19 -0800 (PST) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PN6FKO003652 for ; Thu, 25 Mar 2004 15:06:16 -0800 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i2PN68Id015317; Fri, 26 Mar 2004 00:06:08 +0100 Message-ID: <406365DE.2050006@stesmi.com> Date: Fri, 26 Mar 2004 00:06:06 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord CC: Christoph Hellwig , Chris Wedgwood , "IKARASHI, Seiichi" , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> <20040325124152.GA12078@dingdong.cryptoapps.com> <4062D7E5.6070501@stesmi.com> <20040325132200.GA12333@dingdong.cryptoapps.com> <4062E19A.90207@xfs.org> <20040325140723.GA12558@dingdong.cryptoapps.com> <20040325144519.A23764@infradead.org> <40635F04.6010109@xfs.org> <40636032.3000402@stesmi.com> <4063612E.4030109@xfs.org> <406361F2.6060308@stesmi.com> <4063650B.20600@xfs.org> In-Reply-To: <4063650B.20600@xfs.org> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2612 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 1273 Lines: 37 Hi Steve. >> Yup. That's what's happening. It first does one run with --just-copy >> where it writes the files using the filesystem then reads the same >> files using the blockdevice and it's own filesystem code basically. >> >> // Stefan >> > > And I presume the files are missing? > > The bizzare part of this is that if you read the via the block > device interface, you are looking at the same in memory pages > which xfs uses for the metadata cache. So even if the data has > not hit disk yet, things such as names in directories should > be visible in the metadata cache. Inodes may be more tricky, > since flushing of inodes into the metadata cache is delayed. > > Try this for an experiment, before the run, set > > /proc/sys/fs/xfs/sync_interval > > down to some small number like 1000, pause for a couple > of seconds after calling sync, and then see if grub > can see the files via the block device. > > This tunable controls how long xfs delays writing out > inodes into the metadata cache from their internal format. Alright. I'll try that on my DVD in a few hours and get back to you. Just to verify to be accurate : That /proc entry exists regardless of if xfs is statically compiled or as a module, correct? (ATRPMS makes it a module). // Stefan From owner-linux-xfs@oss.sgi.com Thu Mar 25 15:11:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 15:11:31 -0800 (PST) Received: from relay03.roc.ny.frontiernet.net (relay03.roc.ny.frontiernet.net [66.133.131.36]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PNBSKO004176 for ; Thu, 25 Mar 2004 15:11:28 -0800 Received: (qmail 6806 invoked from network); 25 Mar 2004 23:11:24 -0000 Received: from 208-186-10-249.nrp1.brv.mn.frontiernet.net (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay03.roc.ny.frontiernet.net (FrontierMTA 2.3.18) with SMTP for ; 25 Mar 2004 23:11:24 -0000 Message-ID: <406366E9.1040900@xfs.org> Date: Thu, 25 Mar 2004 17:10:33 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Smietanowski CC: Christoph Hellwig , Chris Wedgwood , "IKARASHI, Seiichi" , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> <20040325124152.GA12078@dingdong.cryptoapps.com> <4062D7E5.6070501@stesmi.com> <20040325132200.GA12333@dingdong.cryptoapps.com> <4062E19A.90207@xfs.org> <20040325140723.GA12558@dingdong.cryptoapps.com> <20040325144519.A23764@infradead.org> <40635F04.6010109@xfs.org> <40636032.3000402@stesmi.com> <4063612E.4030109@xfs.org> <406361F2.6060308@stesmi.com> <4063650B.20600@xfs.org> <406365DE.2050006@stesmi.com> In-Reply-To: <406365DE.2050006@stesmi.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2613 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1497 Lines: 45 Stefan Smietanowski wrote: > Hi Steve. > >>> Yup. That's what's happening. It first does one run with --just-copy >>> where it writes the files using the filesystem then reads the same >>> files using the blockdevice and it's own filesystem code basically. >>> >>> // Stefan >>> >> >> And I presume the files are missing? >> >> The bizzare part of this is that if you read the via the block >> device interface, you are looking at the same in memory pages >> which xfs uses for the metadata cache. So even if the data has >> not hit disk yet, things such as names in directories should >> be visible in the metadata cache. Inodes may be more tricky, >> since flushing of inodes into the metadata cache is delayed. >> >> Try this for an experiment, before the run, set >> >> /proc/sys/fs/xfs/sync_interval >> >> down to some small number like 1000, pause for a couple >> of seconds after calling sync, and then see if grub >> can see the files via the block device. >> >> This tunable controls how long xfs delays writing out >> inodes into the metadata cache from their internal format. > > > Alright. I'll try that on my DVD in a few hours and get back to you. > > Just to verify to be accurate : That /proc entry exists regardless of > if xfs is statically compiled or as a module, correct? (ATRPMS makes > it a module). > > // Stefan > It will exist if you have an xfs filesystem and /proc mounted. Loading an xfs module will create it. Looks like both 2.4 and 2.6 use this now. Steve From owner-linux-xfs@oss.sgi.com Thu Mar 25 18:33:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 18:33:27 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2Q2XPKO014105 for ; Thu, 25 Mar 2004 18:33:25 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2Q2XP9i014104 for linux-xfs@oss.sgi.com; Thu, 25 Mar 2004 18:33:25 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2Q2XNKQ014088 for ; Thu, 25 Mar 2004 18:33:23 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2Q1hoqA012731; Thu, 25 Mar 2004 17:43:50 -0800 Date: Thu, 25 Mar 2004 17:43:50 -0800 Message-Id: <200403260143.i2Q1hoqA012731@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 320] xfsinvutil -i crash with segfault X-Bugzilla-Reason: AssignedTo X-archive-position: 2614 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 911 Lines: 26 http://oss.sgi.com/bugzilla/show_bug.cgi?id=320 ------- Additional Comments From nathans@sgi.com 2004-25-03 17:43 PDT ------- I would have been surprised if that was it, but worth checking (thanks). So, it looks like something is stomping on the libc malloc data structures causing libc to segfault. Possibly a use-after-free, or freeing unalloc'd memory, I would guess. Could you try linking with Electric Fence and then running that on the binary? You can set the environment variable MALLOCLIB to /usr/lib/libefence.a, then do "make distclean && make" in xfsdump - you should still see a segv, but hopefully at the point of failure now, not at some point afterward. Also, could you tar+gz up the contents of your /var/lib/xfsdump directory and send that to me please? thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 25 21:52:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 21:52:24 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2Q5qLKO022644 for ; Thu, 25 Mar 2004 21:52:22 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id DA4D7FB83A; Thu, 25 Mar 2004 23:52:20 -0600 (CST) Date: Thu, 25 Mar 2004 21:52:20 -0800 From: Chris Wedgwood To: Steve Lord Cc: Christoph Hellwig , Stefan Smietanowski , "IKARASHI, Seiichi" , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS Message-ID: <20040326055220.GA20024@dingdong.cryptoapps.com> References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> <20040325124152.GA12078@dingdong.cryptoapps.com> <4062D7E5.6070501@stesmi.com> <20040325132200.GA12333@dingdong.cryptoapps.com> <4062E19A.90207@xfs.org> <20040325140723.GA12558@dingdong.cryptoapps.com> <20040325144519.A23764@infradead.org> <40635F04.6010109@xfs.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40635F04.6010109@xfs.org> Content-Transfer-Encoding: 8bit X-archive-position: 2615 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 263 Lines: 11 On Thu, Mar 25, 2004 at 04:36:52PM -0600, Steve Lord wrote: > And thinking about it some more, having grub make the filesystem > remount readonly would force everything down to disk unlike just > doing a sync call. What about freeze/unfreeze instead? --cw From owner-linux-xfs@oss.sgi.com Thu Mar 25 22:33:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 22:33:43 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2Q6XQKO024462 for ; Thu, 25 Mar 2004 22:33:26 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2Q6XQFn024461 for linux-xfs@oss.sgi.com; Thu, 25 Mar 2004 22:33:26 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2Q6XNKQ024445 for ; Thu, 25 Mar 2004 22:33:24 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2Q5lqsN022566; Thu, 25 Mar 2004 21:47:52 -0800 Date: Thu, 25 Mar 2004 21:47:52 -0800 Message-Id: <200403260547.i2Q5lqsN022566@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 321] XFS internal error, xfs_force_shutdown on 1.2TB fileserver. X-Bugzilla-Reason: AssignedTo X-archive-position: 2616 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1745 Lines: 51 http://oss.sgi.com/bugzilla/show_bug.cgi?id=321 ericy@outblaze.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sandeen@sgi.com ------- Additional Comments From ericy@outblaze.com 2004-25-03 21:47 PDT ------- Hi Eric, The machine actually has filesystem < 1TB because it's running RAID10: Array Unit 0 Striped Mirrors 64K (RAID 10) 600.14 GB OK Subunit 0 Mirror (RAID 1) OK o Port 5 WDC WD2000JB-32FUA0 200.04 GB OK o Port 4 WDC WD2000JB-32FUA0 200.04 GB OK Subunit 1 Mirror (RAID 1) OK o Port 3 WDC WD2000JB-32FUA0 200.04 GB OK o Port 2 WDC WD2000JB-32FUA0 200.04 GB OK Subunit 2 Mirror (RAID 1) OK o Port 1 WDC WD2000JB-32FUA0 200.04 GB OK o Port 0 WDC WD2000JB-32FUA0 200.04 GB OK # sfdisk -l Disk /dev/sda: 72963 cylinders, 255 heads, 63 sectors/track Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/sda1 * 0+ 509 510- 4096543+ 83 Linux /dev/sda2 510 1019 510 4096575 83 Linux /dev/sda3 1020 1401 382 3068415 83 Linux /dev/sda4 1402 72962 71561 574813732+ 5 Extended /dev/sda5 1402+ 1663 262- 2104483+ 82 Linux swap /dev/sda6 1664+ 37182 35519- 285306336 83 Linux /dev/sda7 37183+ 72962 35780- 287402818+ 83 Linux Regards, Eric Yu Outblaze Ltd. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Mar 25 23:33:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 23:33:37 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2Q7XQKO026566 for ; Thu, 25 Mar 2004 23:33:26 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2Q7XQ3K026565 for linux-xfs@oss.sgi.com; Thu, 25 Mar 2004 23:33:26 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2Q7XOKQ026549 for ; Thu, 25 Mar 2004 23:33:24 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2Q6bXar024988; Thu, 25 Mar 2004 22:37:33 -0800 Date: Thu, 25 Mar 2004 22:37:33 -0800 Message-Id: <200403260637.i2Q6bXar024988@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 321] XFS internal error, xfs_force_shutdown on 1.2TB fileserver. X-Bugzilla-Reason: AssignedTo X-archive-position: 2617 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 443 Lines: 18 http://oss.sgi.com/bugzilla/show_bug.cgi?id=321 ericy@outblaze.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Mar 26 00:33:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 00:33:33 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2Q8XSKO001169 for ; Fri, 26 Mar 2004 00:33:28 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2Q8XSBR001167 for linux-xfs@oss.sgi.com; Fri, 26 Mar 2004 00:33:28 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2Q8XQKU001133 for ; Fri, 26 Mar 2004 00:33:27 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2Q8UoA0001036; Fri, 26 Mar 2004 00:30:50 -0800 Date: Fri, 26 Mar 2004 00:30:50 -0800 Message-Id: <200403260830.i2Q8UoA0001036@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 322] New: xfs internal error X-Bugzilla-Reason: AssignedTo X-archive-position: 2619 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 4636 Lines: 111 http://oss.sgi.com/bugzilla/show_bug.cgi?id=322 Summary: xfs internal error Product: Linux XFS Version: Current Platform: AMD OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: rutger@artibit.com I run XFS as my / partition on Linux 2.6.4 on an AMD64 in pure 64 bit. This bug could be related to http://bugs.gentoo.org/show_bug.cgi?id=43971 Luckily my system could recover every time at reboot. I have gathered some messages from my system log, and included them below. Filesystem "sda3": XFS internal error xfs_da_do_buf(1) at line 2176 of file fs/xfs/xfs_da_btree.c. Caller 0xffffffff802193f4 Call Trace:{xfs_da_do_buf+739} {pagebuf_get+194} {xfs_da_do_buf+1324} {xfs_da_read_buf+36} {xfs_dir2_leafn_lookup_int+731} {xfs_dir2_leafn_lookup_int+731} {xfs_da_node_lookup_int+518} {xfs_dir2_node_lookup+67} {xfs_dir2_lookup+255} {xfs_dir_lookup_int+81} {xfs_lookup+96} {linvfs_lookup+70} {real_lookup+132} {do_lookup+102} {link_path_walk+2368} {__user_walk+62} {vfs_lstat+32} {sys_newlstat+31} {system_call+124} xfs_da_do_buf: bno 4030465 dir: inode 184549508 Filesystem "sda3": XFS internal error xfs_da_do_buf(1) at line 2176 of file fs/xfs/xfs_da_btree.c. Caller 0xffffffff802193f4 Call Trace:{xfs_da_do_buf+739} {pagebuf_get+194} {xfs_da_do_buf+1324} {xfs_da_read_buf+36} {xfs_dir2_leafn_lookup_int+731} {xfs_dir2_leafn_lookup_int+731} {xfs_da_node_lookup_int+518} {xfs_dir2_node_lookup+67} {xfs_dir2_lookup+255} {xfs_dir_lookup_int+81} {xfs_lookup+96} {linvfs_lookup+70} {real_lookup+132} {do_lookup+102} {link_path_walk+2368} {__user_walk+62} {vfs_lstat+32} {sys_newlstat+31} {system_call+124} xfs_da_do_buf: bno 1277953 dir: inode 184549508 Filesystem "sda3": XFS internal error xfs_da_do_buf(1) at line 2176 of file fs/xfs/xfs_da_btree.c. Caller 0xffffffff802193f4 Call Trace:{xfs_da_do_buf+739} {pagebuf_get+194} {xfs_da_do_buf+1324} {xfs_da_read_buf+36} {xfs_dir2_leafn_lookup_int+731} {xfs_dir2_leafn_lookup_int+731} {xfs_da_node_lookup_int+518} {xfs_dir2_node_lookup+67} {xfs_dir2_lookup+255} {xfs_dir_lookup_int+81} {xfs_lookup+96} {linvfs_lookup+70} {real_lookup+132} {do_lookup+102} {link_path_walk+2368} {__user_walk+62} {vfs_lstat+32} {sys_newlstat+31} {system_call+124} xfs_da_do_buf: bno 1277955 dir: inode 184549508 Filesystem "sda3": XFS internal error xfs_da_do_buf(1) at line 2176 of file fs/xfs/xfs_da_btree.c. Caller 0xffffffff802193f4 Call Trace:{xfs_da_do_buf+739} {pagebuf_get+194} {xfs_da_do_buf+1324} {xfs_da_read_buf+36} {xfs_dir2_leafn_lookup_int+731} {xfs_dir2_leafn_lookup_int+731} {xfs_da_node_lookup_int+518} {xfs_dir2_node_lookup+67} {xfs_dir2_lookup+255} {xfs_dir_lookup_int+81} {xfs_lookup+96} {linvfs_lookup+70} {real_lookup+132} {do_lookup+102} {link_path_walk+2368} {__user_walk+62} {vfs_lstat+32} {sys_newlstat+31} {system_call+124} xfs_da_do_buf: bno 5242884 dir: inode 184549508 ...and more of these ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Mar 26 00:33:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 00:33:31 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2Q8XRKO001160 for ; Fri, 26 Mar 2004 00:33:28 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2Q8XRet001159 for linux-xfs@oss.sgi.com; Fri, 26 Mar 2004 00:33:27 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2Q8XQKQ001133 for ; Fri, 26 Mar 2004 00:33:26 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2Q8EkYY027961; Fri, 26 Mar 2004 00:14:46 -0800 Date: Fri, 26 Mar 2004 00:14:46 -0800 Message-Id: <200403260814.i2Q8EkYY027961@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 320] xfsinvutil -i crash with segfault X-Bugzilla-Reason: AssignedTo X-archive-position: 2618 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2325 Lines: 61 http://oss.sgi.com/bugzilla/show_bug.cgi?id=320 ------- Additional Comments From Nicolas.Kowalski@imag.fr 2004-26-03 00:14 PDT ------- After tweaking the Makefile to make xfsinvutil build with electric-fence (-lpthread was missing to the linker), here is a gdb backtrace: # gdb /usr/sbin/xfsinvutil GNU gdb 2002-04-01-cvs Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"... (gdb) set args -i (gdb) r Starting program: /usr/sbin/xfsinvutil -i [New Thread 1024 (LWP 2423)] Electric Fence 2.1 Copyright (C) 1987-1998 Bruce Perens. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 2423)] 0x400e1d85 in mempcpy () from /lib/libc.so.6 (gdb) bt #0 0x400e1d85 in mempcpy () from /lib/libc.so.6 #1 0x400d8488 in _IO_default_xsputn () from /lib/libc.so.6 #2 0x400b90eb in vfprintf () from /lib/libc.so.6 #3 0x400d00c3 in vsprintf () from /lib/libc.so.6 #4 0x400c040d in sprintf () from /lib/libc.so.6 #5 0x080500dc in generate_stobj_menu (startnode=0x401a1ff4, level=2, StObjFileName=0x401a9fb8 "/var/lib/xfsdump/inventory/6514a9bc-4180-40d2-9f94-59c2d590b3b7.StObj") at stobj.c:437 #6 0x0804e8b2 in generate_invidx_menu ( inv_path=0x80545a0 "/var/lib/xfsdump/inventory", startnode=0x40193ff4, level=1, idxFileName=0x40199fb4 "/var/lib/xfsdump/inventory/c184a2dc-6b9b-4d01-8181-c6fd34daa176.InvIndex") at invidx.c:973 #7 0x0804c785 in generate_fstab_menu ( inv_path=0x80545a0 "/var/lib/xfsdump/inventory", startnode=0x0, level=0, fstabname=0x4018bfdc "/var/lib/xfsdump/inventory/fstab") at fstab.c:283 #8 0x0804bf73 in generate_menu ( inv_path=0x80545a0 "/var/lib/xfsdump/inventory") at cmenu.c:532 #9 0x0804c0ae in invutil_interactive ( inv_path=0x80545a0 "/var/lib/xfsdump/inventory", mountpt=0x0, uuidp=0x0, timeSecs=0) at cmenu.c:587 #10 0x0804a0ed in main (argc=2, argv=0xbffffd34) at invutil.c:216 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Mar 26 00:36:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 00:36:33 -0800 (PST) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.227]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2Q8aJKO001980 for ; Fri, 26 Mar 2004 00:36:20 -0800 Received: by heretic.physik.fu-berlin.de (8.12.10/8.12.10) with ESMTP id i2Q8a66d029751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Mar 2004 09:36:09 +0100 Received: (from thimm@localhost) by neu.nirvana (8.12.10/8.12.10/Submit) id i2Q8ZuoE009489; Fri, 26 Mar 2004 09:35:56 +0100 Date: Fri, 26 Mar 2004 09:35:52 +0100 From: Axel Thimm To: Kjell Randa Cc: linux-xfs@oss.sgi.com, Takeru KOMORIYA , Dan Yocum Subject: Re: Kernel oops in 2.4.22-1.2174.nptl_37.rhfc1.atsmp Message-ID: <20040326083552.GL28579@neu.nirvana> References: <405E219A.7080607@broadpark.no> <20040325063726.GA23797@neu.nirvana> <40635166.6040705@broadpark.no> Mime-Version: 1.0 Content-type: text/plain Content-Disposition: inline In-Reply-To: <40635166.6040705@broadpark.no> User-Agent: Mutt/1.4.2i Content-Transfer-Encoding: 8bit X-archive-position: 2620 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@ATrpms.net Precedence: bulk X-list: linux-xfs Content-Length: 2190 Lines: 65 On Thu, Mar 25, 2004 at 10:38:46PM +0100, Kjell Randa wrote: > Axel Thimm wrote: > > >On Mon, Mar 22, 2004 at 12:13:30AM +0100, Kjell Randa wrote: > > > I have been using XFS for more than two years without any > > > problems, but lately I have started to get oops messages during > > > time of heavy I/O load. The system survives and seems healty > > > afterwords. This may be related to upgrade to the current kernel. > > What was the kernel running before the upgrade? An atrpms kernel > > or something else? > It was an atrpms kernel. I have been ugrading the kernel regulary from > the atrmp site for the last half year. OK, the changes to the previous kernel are some Red Hat patches and lm_sensors/i2c upgrades. do you remember which atrpms kernel you were using? Below are the changes to 2.4.22-1.2166.nptl_35.rhfc1.at. There were no changes to md/lvm, but perhaps another touched subsystem has become instable or incompatible to XFS? +* Sat Feb 21 2004 Axel Thimm +- Updated i2c/lm_sensors to 2.8.4 (thanks to Jean Delvare + ). + +* Wed Feb 18 2004 Dave Jones +- Fix security problem in gamma DRI driver. +- Drop broken fix for 92129 + +* Tue Feb 17 2004 Dave Jones +- Fix leak in SSTFB driver. + +* Sat Feb 14 2004 Dave Jones +- aacraid fix for #92129 + +* Fri Feb 13 2004 Dave Jones +- Fix building of vt8231.o + +* Thu Feb 5 2004 Dave Jones +- Check do_mremap return values (CAN-2004-0077) + +* Mon Feb 02 2004 Dave Jones +- Disable stack overflow checking. +- More bits from 2.4.25pre + - Fix ipt_conntrack/ipt_state module refcounting. + - Zero last byte of mount option page + - AMD64 update + - Fix deep stack usage in ncpfs + * Tue Jan 27 2004 Stefan Smietanowski - Update to latest libata patch. -- Axel.Thimm at ATrpms.net -- Attached file included as plaintext by Ecartis -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAY+toQBVS1GOamfERAoLYAJ9qA1EZllO29ujzQ5D3y+1Cwew5DACeJ2Qe VFDk0jsR3NSoTywHJ6S/bYQ= =zlRT -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Mar 26 01:33:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 01:33:51 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2Q9XQKO005343 for ; Fri, 26 Mar 2004 01:33:26 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2Q9XQ1h005342 for linux-xfs@oss.sgi.com; Fri, 26 Mar 2004 01:33:26 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2Q9XOKQ005328 for ; Fri, 26 Mar 2004 01:33:24 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2Q9G0ON004661; Fri, 26 Mar 2004 01:16:00 -0800 Date: Fri, 26 Mar 2004 01:16:00 -0800 Message-Id: <200403260916.i2Q9G0ON004661@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 320] xfsinvutil -i crash with segfault X-Bugzilla-Reason: AssignedTo X-archive-position: 2621 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1563 Lines: 46 http://oss.sgi.com/bugzilla/show_bug.cgi?id=320 tes@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #112 is|0 |1 obsolete| | ------- Additional Comments From tes@sgi.com 2004-26-03 01:13 PDT ------- Created an attachment (id=114) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=114&action=view) xfsinvutil segv fix attempt#2 Looks like xfsdump/invutil/stobj.c on line 432 may be not allocating a big enough txt string. It would be nicer to use snprintf() here and perhaps use a string length which is more accurate based on the length of session->session->s_label and a macro constant for the rest of the string.....but for now keep it simple. ------- Additional Comments From tes@sgi.com 2004-26-03 01:15 PDT ------- Looks like xfsdump/invutil/stobj.c on line 432 may be not allocating a big enough txt string. It would be nicer to use snprintf() here and perhaps use a string length which is more accurate based on the length of session->session->s_label and a macro constant for the rest of the string.....but for now can you just try making 432 txt = malloc(60); to something bigger, say: 432 txt = malloc(60+strlen(session->session->s_label)); and see if that helps. I've attached patch.....I'm new to bugzilla... --Tim ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Mar 26 02:33:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 02:33:30 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2QAXQKO008788 for ; Fri, 26 Mar 2004 02:33:26 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2QAXQ8C008787 for linux-xfs@oss.sgi.com; Fri, 26 Mar 2004 02:33:26 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2QAXOKQ008773 for ; Fri, 26 Mar 2004 02:33:25 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2Q9sCx5007012; Fri, 26 Mar 2004 01:54:12 -0800 Date: Fri, 26 Mar 2004 01:54:12 -0800 Message-Id: <200403260954.i2Q9sCx5007012@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 320] xfsinvutil -i crash with segfault X-Bugzilla-Reason: AssignedTo X-archive-position: 2622 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 309 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=320 ------- Additional Comments From Nicolas.Kowalski@imag.fr 2004-26-03 01:54 PDT ------- With this patch, it works ! :-) Many thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Mar 26 03:33:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 03:33:31 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2QBXRKO012889 for ; Fri, 26 Mar 2004 03:33:27 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2QBXRjo012888 for linux-xfs@oss.sgi.com; Fri, 26 Mar 2004 03:33:27 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2QBXPKQ012865 for ; Fri, 26 Mar 2004 03:33:25 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2QAeAuW011040; Fri, 26 Mar 2004 02:40:10 -0800 Date: Fri, 26 Mar 2004 02:40:10 -0800 Message-Id: <200403261040.i2QAeAuW011040@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 318] kernel BUG at fs/xfs/support/debug.c:106 X-Bugzilla-Reason: AssignedTo X-archive-position: 2623 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 622 Lines: 23 http://oss.sgi.com/bugzilla/show_bug.cgi?id=318 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From hch@xfs.org 2004-26-03 02:40 PDT ------- Known but not yet fixed issue with Linux 2.6 *** This bug has been marked as a duplicate of 309 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Mar 26 05:49:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 05:50:02 -0800 (PST) Received: from mailman1.ppco.com (mailman1.ppco.com [138.32.33.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2QDnpKO001881 for ; Fri, 26 Mar 2004 05:49:51 -0800 Received: from bvlextrd02.conoco.net (trend2.ppco.com [138.32.33.145]) by mailman1.ppco.com (8.12.8/8.12.8) with ESMTP id i2QDnmar013641 for ; Fri, 26 Mar 2004 07:49:48 -0600 Received: from mail1.ppco.com ([138.32.31.56]) by bvlextrd02 with trend_isnt_name_B; Fri, 26 Mar 2004 07:49:46 -0600 Received: from bvlexbh1.conoco.net (bvlexbh1.conoco.net [138.32.45.41]) by mail1.ppco.com (8.11.6+Sun/8.11.6) with ESMTP id i2QDnj112935; Fri, 26 Mar 2004 07:49:45 -0600 (CST) Received: from hoexbh2.conoco.net ([144.46.83.12]) by bvlexbh1.conoco.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 26 Mar 2004 07:49:45 -0600 Received: from hoexmb3.conoco.net ([144.46.87.144]) by hoexbh2.conoco.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 26 Mar 2004 07:49:45 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: >1 TB RAID servers Date: Fri, 26 Mar 2004 07:49:44 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: >1 TB RAID servers Thread-Index: AcQSsnjA14QyntsdQVOS+lM6G173fAAhmW1w From: "Rivera, Angel R" To: "Steve Lord" , Cc: , "Joshua Baker-LePain" , "Daryl Herzmann" , X-OriginalArrivalTime: 26 Mar 2004 13:49:45.0082 (UTC) FILETIME=[324765A0:01C41339] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i2QDnpKO001884 X-archive-position: 2624 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Angel.R.Rivera@conocophillips.com Precedence: bulk X-list: linux-xfs Content-Length: 826 Lines: 28 -----Original Message----- From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com]On Behalf Of Steve Lord Sent: Thursday, March 25, 2004 3:44 PM To: christian.guggenberger@physik.uni-regensburg.de Cc: hch@infradead.org; Joshua Baker-LePain; Daryl Herzmann; linux-xfs@oss.sgi.com Subject: Re: >1 TB RAID servers [snip] Not sure which are supposed to be safe, all you can do is ask around as to what hardware/software folks are successfully using with 2.4 for filesystems greater than 1Tbyte. As you can see from Christoph's answer, 2.6 with the large block device option is the preferred option. ARR> We have some 50TB in 1.4TB chucks and they are very stable. With the large block patch you can get them over 2TB with the 2.4 kernel. We are testing the 2.6 kernel because of read-starvation issues. From owner-linux-xfs@oss.sgi.com Fri Mar 26 06:10:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 06:10:39 -0800 (PST) Received: from mailman1.ppco.com (mailman1.ppco.com [138.32.33.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2QEAYKO002781 for ; Fri, 26 Mar 2004 06:10:34 -0800 Received: from bvlextrd02.conoco.net (trend2.ppco.com [138.32.33.145]) by mailman1.ppco.com (8.12.8/8.12.8) with ESMTP id i2QEAXar025713 for ; Fri, 26 Mar 2004 08:10:33 -0600 Received: from mail1.ppco.com ([138.32.31.56]) by bvlextrd02 with trend_isnt_name_B; Fri, 26 Mar 2004 08:10:32 -0600 Received: from bvlexbh1.conoco.net (bvlexbh1.conoco.net [138.32.45.41]) by mail1.ppco.com (8.11.6+Sun/8.11.6) with ESMTP id i2QEAW127466; Fri, 26 Mar 2004 08:10:32 -0600 (CST) Received: from hoexbh1.conoco.net ([144.46.83.11]) by bvlexbh1.conoco.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 26 Mar 2004 08:10:12 -0600 Received: from hoexmb3.conoco.net ([144.46.87.144]) by hoexbh1.conoco.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 26 Mar 2004 08:10:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: >1 TB RAID servers Date: Fri, 26 Mar 2004 08:10:11 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: >1 TB RAID servers Thread-Index: AcQSsoylnwytzYalTme2B0+tEPtYbAAiUo3w From: "Rivera, Angel R" To: "Austin Gonyou" , "Christoph Hellwig" Cc: "Christian Guggenberger" , "Steve Lord" , "Joshua Baker-LePain" , "Daryl Herzmann" , "XFS List" X-OriginalArrivalTime: 26 Mar 2004 14:10:12.0231 (UTC) FILETIME=[0DB77970:01C4133C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i2QEAYKO002782 X-archive-position: 2625 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Angel.R.Rivera@conocophillips.com Precedence: bulk X-list: linux-xfs Content-Length: 989 Lines: 26 We found these problems as well, but were able to resolve them by taking a look at the number of inodes. Here is a looksie into our current test box Filesystem Size Used Avail Use% Mounted on /dev/sda1 9.7G 6.6G 2.6G 73% / none 1012M 0 1012M 0% /dev/shm /dev/sda2 2.9G 86M 2.7G 4% /tmp /dev/md0 2.8T 11G 2.8T 1% /ptmp/hoepld69 -----Original Message----- From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com]On Behalf Of Austin Gonyou Sent: Thursday, March 25, 2004 3:45 PM To: Christoph Hellwig Cc: Christian Guggenberger; Steve Lord; Joshua Baker-LePain; Daryl Herzmann; XFS List Subject: Re: >1 TB RAID servers We still use that old 2.4.19 stuff on volumes that are 1.5T max. Going to about 1.7T we notice issues for sure, mainly in the properly reported size. it might show up as 300M, or 1T. 1.5 is the max we've been able to get away with and not have issues of that nature. From owner-linux-xfs@oss.sgi.com Fri Mar 26 06:33:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 06:33:29 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2QEXRKO003777 for ; Fri, 26 Mar 2004 06:33:27 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2QEXRZn003776 for linux-xfs@oss.sgi.com; Fri, 26 Mar 2004 06:33:27 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2QEXPKO003760 for ; Fri, 26 Mar 2004 06:33:25 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2QESAAZ003643; Fri, 26 Mar 2004 06:28:10 -0800 Date: Fri, 26 Mar 2004 06:28:10 -0800 Message-Id: <200403261428.i2QESAAZ003643@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 321] XFS internal error, xfs_force_shutdown on 1.2TB fileserver. X-Bugzilla-Reason: AssignedTo X-archive-position: 2626 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 687 Lines: 23 http://oss.sgi.com/bugzilla/show_bug.cgi?id=321 ------- Additional Comments From sandeen@sgi.com 2004-26-03 06:28 PDT ------- Hm, ok. I saw the "1.2T" in the subject line and assumed that it was, well... 1.2T. :) For repair, please get the latest packages from oss, I'm building them now and they should be available in about an hour. See if repair completes correctly, and if the problem returns (or if repair still fails) please update the bug. Also, from below you have messages about sd(8,7) shutting down, but you posted xfs_info from sda6, I think. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Mar 26 06:45:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 06:45:45 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2QEjfKO004566 for ; Fri, 26 Mar 2004 06:45:41 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2QGmrAv017366 for ; Fri, 26 Mar 2004 08:48:53 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2QEjZKe35884856 for ; Fri, 26 Mar 2004 08:45:35 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i2QEjUEr3341354 for ; Fri, 26 Mar 2004 08:45:35 -0600 (CST) Date: Fri, 26 Mar 2004 08:45:30 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: linux-xfs@oss.sgi.com Subject: Updated userspace on oss.sgi.com Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2627 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 204 Lines: 9 Hi Gang - Just a note, I've rebuilt all userspace packages (and created new tarballs) from CVS and placed them at ftp://oss.sgi.com/projects/xfs/cmd_rpms ftp://oss.sgi.com/projects/xfs/cmd_tars -Eric From owner-linux-xfs@oss.sgi.com Fri Mar 26 06:54:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 06:54:30 -0800 (PST) Received: from linux-sxs.org (d47-69-170-59.col.wideopenwest.com [69.47.59.170]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2QEsRKO005336 for ; Fri, 26 Mar 2004 06:54:28 -0800 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.11/8.12.11) with ESMTP id i2QEuvDM016974; Fri, 26 Mar 2004 09:56:57 -0500 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.11/8.12.10/Submit) with ESMTP id i2QEuuFo016971; Fri, 26 Mar 2004 09:56:57 -0500 Date: Fri, 26 Mar 2004 09:56:56 -0500 (EST) From: Net Llama! To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: Updated userspace on oss.sgi.com In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.41 Content-Transfer-Encoding: 8bit X-archive-position: 2628 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 477 Lines: 20 Thanks, your work is appreciated. On Fri, 26 Mar 2004, Eric Sandeen wrote: > Hi Gang - > > Just a note, I've rebuilt all userspace packages (and created new > tarballs) from CVS and placed them at > ftp://oss.sgi.com/projects/xfs/cmd_rpms > ftp://oss.sgi.com/projects/xfs/cmd_tars > > -Eric > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Fri Mar 26 06:59:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 06:59:43 -0800 (PST) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2QExWKO006020 for ; Fri, 26 Mar 2004 06:59:33 -0800 Received: from mail-veri.imag.fr (pave.imag.fr [129.88.43.12]) by imag.imag.fr (8.12.10/8.12.10) with ESMTP id i2QExSRL022183 for ; Fri, 26 Mar 2004 15:59:28 +0100 (CET) Received: from obiou.imag.fr ([129.88.43.2] helo=obiou.imag.fr.imag.fr ident=kowalski) by mail-veri.imag.fr with esmtp (Exim 3.35 #1 (Debian)) id 1B6snv-0004cG-00 for ; Fri, 26 Mar 2004 15:59:27 +0100 To: linux-xfs@oss.sgi.com Subject: debs (was: Updated userspace on oss.sgi.com) References: From: Nicolas Kowalski Mail-Copies-To: never Date: Fri, 26 Mar 2004 15:59:27 +0100 In-Reply-To: (Eric Sandeen's message of "Fri, 26 Mar 2004 08:45:30 -0600 (CST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information Content-Transfer-Encoding: 8bit X-archive-position: 2629 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 497 Lines: 17 Eric Sandeen writes: > Just a note, I've rebuilt all userspace packages (and created new > tarballs) from CVS and placed them at > ftp://oss.sgi.com/projects/xfs/cmd_rpms > ftp://oss.sgi.com/projects/xfs/cmd_tars Just a question for XFS+Debian users: is there a way to built the debian packages with the default Makefile provided ? Each time I update my CVS copy (with cvsup) of xfs-cmds, I have to add "debian" as argument to Makepkgs in the cmds rule. Thanks. -- Nicolas From owner-linux-xfs@oss.sgi.com Fri Mar 26 07:22:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 07:22:34 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2QFMMKO007082 for ; Fri, 26 Mar 2004 07:22:24 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2QHPYCL022702 for ; Fri, 26 Mar 2004 09:25:34 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2QFMFKe35874938; Fri, 26 Mar 2004 09:22:15 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1B6t9y-0004py-00; Fri, 26 Mar 2004 09:22:14 -0600 Subject: TAKE 911915 - permission checks Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Fri, 26 Mar 2004 09:22:14 -0600 X-archive-position: 2630 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 617 Lines: 19 Date: Fri Mar 26 07:21:29 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:169135a fs/xfs/xfs_dfrag.c - 1.43 - check both inodes are in the same fs and of the same type in xfs_swapext fs/xfs/linux-2.6/xfs_ioctl.c - 1.107 - check CAP_SYS_ADMIN for error injection ioctls, fix r/o filesystem check in xfs_ioc_space fs/xfs/linux-2.4/xfs_ioctl.c - 1.106 - check CAP_SYS_ADMIN for error injection ioctls, fix r/o filesystem check in xfs_ioc_space From owner-linux-xfs@oss.sgi.com Fri Mar 26 07:25:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 07:25:44 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2QFPWKO007579 for ; Fri, 26 Mar 2004 07:25:34 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1B6tD6-0001mN-FQ; Fri, 26 Mar 2004 15:25:28 +0000 Date: Fri, 26 Mar 2004 15:25:28 +0000 From: Christoph Hellwig To: Nicolas Kowalski Cc: linux-xfs@oss.sgi.com Subject: Re: debs (was: Updated userspace on oss.sgi.com) Message-ID: <20040326152528.A6802@infradead.org> References: Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Nicolas.Kowalski@imag.fr on Fri, Mar 26, 2004 at 03:59:27PM +0100 Content-Transfer-Encoding: 8bit X-archive-position: 2631 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 601 Lines: 14 On Fri, Mar 26, 2004 at 03:59:27PM +0100, Nicolas Kowalski wrote: > > Just a note, I've rebuilt all userspace packages (and created new > > tarballs) from CVS and placed them at > > ftp://oss.sgi.com/projects/xfs/cmd_rpms > > ftp://oss.sgi.com/projects/xfs/cmd_tars > > Just a question for XFS+Debian users: is there a way to built the > debian packages with the default Makefile provided ? Each time I > update my CVS copy (with cvsup) of xfs-cmds, I have to add "debian" as > argument to Makepkgs in the cmds rule. I usually run dpkg-buildpackage directly in each of the toplevel subdirectories. From owner-linux-xfs@oss.sgi.com Fri Mar 26 07:33:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 07:33:40 -0800 (PST) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2QFXaKO008220 for ; Fri, 26 Mar 2004 07:33:37 -0800 Received: from mail-veri.imag.fr (pave.imag.fr [129.88.43.12]) by imag.imag.fr (8.12.10/8.12.10) with ESMTP id i2QFXSRL005147 for ; Fri, 26 Mar 2004 16:33:29 +0100 (CET) Received: from obiou.imag.fr ([129.88.43.2] helo=obiou.imag.fr.imag.fr ident=kowalski) by mail-veri.imag.fr with esmtp (Exim 3.35 #1 (Debian)) id 1B6tKq-0001wT-00 for ; Fri, 26 Mar 2004 16:33:28 +0100 To: linux-xfs@oss.sgi.com Subject: Re: debs References: <20040326152528.A6802@infradead.org> From: Nicolas Kowalski Mail-Copies-To: never Date: Fri, 26 Mar 2004 16:33:28 +0100 In-Reply-To: <20040326152528.A6802@infradead.org> (Christoph Hellwig's message of "Fri, 26 Mar 2004 15:25:28 +0000") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information Content-Transfer-Encoding: 8bit X-archive-position: 2632 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 498 Lines: 17 Christoph Hellwig writes: > On Fri, Mar 26, 2004 at 03:59:27PM +0100, Nicolas Kowalski wrote: >> >> Just a question for XFS+Debian users: is there a way to built the >> debian packages with the default Makefile provided ? Each time I >> update my CVS copy (with cvsup) of xfs-cmds, I have to add "debian" as >> argument to Makepkgs in the cmds rule. > > I usually run dpkg-buildpackage directly in each of the toplevel > subdirectories. Ok, thanks for the tip. -- Nicolas From owner-linux-xfs@oss.sgi.com Fri Mar 26 07:36:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 07:36:36 -0800 (PST) Received: from eik.ii.uib.no (eik.ii.uib.no [129.177.16.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2QFaWKO008684 for ; Fri, 26 Mar 2004 07:36:34 -0800 Received: from lapprose.ii.uib.no ([129.177.20.37]:35877) by eik.ii.uib.no with esmtp (TLSv1:AES256-SHA:256) (Exim 4.30) id 1B6tNe-0000pz-W1; Fri, 26 Mar 2004 16:36:22 +0100 Received: (from jfm@localhost) by lapprose.ii.uib.no (8.12.8/8.12.8/Submit) id i2QFaMib031208; Fri, 26 Mar 2004 16:36:22 +0100 Date: Fri, 26 Mar 2004 16:36:22 +0100 From: Jan-Frode Myklebust To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Updated userspace on oss.sgi.com Message-ID: <20040326153622.GB30389@ii.uib.no> References: Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: 8bit X-archive-position: 2633 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: janfrode@parallab.uib.no Precedence: bulk X-list: linux-xfs Content-Length: 548 Lines: 16 On Fri, Mar 26, 2004 at 08:45:30AM -0600, Eric Sandeen wrote: > > Just a note, I've rebuilt all userspace packages (and created new > tarballs) from CVS and placed them at > ftp://oss.sgi.com/projects/xfs/cmd_rpms > ftp://oss.sgi.com/projects/xfs/cmd_tars > Are there any plans for updated kernel-rpms? Especially a version for RHEL-3 would be much appreciated. The testing/RHEL-version didn't boot on my systems (because of root on LVM, or maybe problems with devfs?), so I had to revert to ext3 on the latest fileserver I set up :( -jf From owner-linux-xfs@oss.sgi.com Fri Mar 26 07:53:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 07:53:17 -0800 (PST) Received: from corpmail.outblaze.com (corpmail.outblaze.com [203.86.166.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2QFrCKO009584 for ; Fri, 26 Mar 2004 07:53:13 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by corpmail.outblaze.com (Postfix) with ESMTP id E882437AC3 for ; Fri, 26 Mar 2004 15:53:07 +0000 (GMT) Received: from yusufg.portal2.com (210-177-227-130.outblaze.com [210.177.227.130]) by corpmail.outblaze.com (Postfix) with SMTP id 3B68916DDA8 for ; Fri, 26 Mar 2004 15:53:07 +0000 (GMT) Received: (qmail 21314 invoked by uid 500); 26 Mar 2004 15:53:04 -0000 Date: Fri, 26 Mar 2004 23:53:04 +0800 From: Yusuf Goolamabbas To: linux-xfs@oss.sgi.com Subject: Error compiling xfsprogs-2.6.8 on Fedora Core 1 with 2.6.5-rc2-mm3 Message-ID: <20040326155304.GA21284@outblaze.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.11; VAE: 6.24.0.7; VDF: 6.24.0.73; host: corpmail.outblaze.com) Content-Transfer-Encoding: 8bit X-archive-position: 2634 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yusufg@outblaze.com Precedence: bulk X-list: linux-xfs Content-Length: 908 Lines: 22 I have 2.6.5-rc2-mm3 running on Fedora Core 1 and have xfsprogs-2.5.6 installed on that box, I just download xfsprogs-2.6.8 and got the following error whilst trying to compile it === io === gcc -O1 -g -DDEBUG -funsigned-char -Wall -I../include -DVERSION=\"2.6.8\" -DLOCALEDIR=\"/usr/local/site/xfsprogs/share/locale\" -DPACKAGE=\"xfsprogs\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_FADVISE -c -o command.o command.c command.c:36:16: io.h: No such file or directory command.c: In function `command': command.c:79: error: `file' undeclared (first use in this function) command.c:79: error: (Each undeclared identifier is reported only once command.c:79: error: for each function it appears in.) command.c:83: error: `mapping' undeclared (first use in this function) command.c:88: error: `IO_FOREIGN' undeclared (first use in this function) make[1]: *** [command.o] Error 1 make: *** [default] Error 2 From owner-linux-xfs@oss.sgi.com Fri Mar 26 08:02:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 08:03:03 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2QG2lKO010347 for ; Fri, 26 Mar 2004 08:02:47 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2QFmLf0006214 for ; Fri, 26 Mar 2004 09:48:21 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2QFmKKe35904637; Fri, 26 Mar 2004 09:48:20 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i2QFmKEr3350432; Fri, 26 Mar 2004 09:48:20 -0600 (CST) Date: Fri, 26 Mar 2004 09:48:20 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jan-Frode Myklebust cc: linux-xfs@oss.sgi.com Subject: Re: Updated userspace on oss.sgi.com In-Reply-To: <20040326153622.GB30389@ii.uib.no> Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2635 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1508 Lines: 38 Here's the plan for kernelspace... There is a body of XFS code that is currently in a release process for a couple of SGI products, and this includes surrounding RH9 and RHEL kernels. I plan to put that all out on OSS as the next "formal" xfs release. The caveats are that the RH kernels have other changes - devfs, lbd, kdb, etc that people may or may not want. But, in the grand open source tradition, you can always edit the specfile and rebuild to your heart's content. :) Also, the XFS code is not shiny new, due to the fact that it is part of a more conservative internal release process for paying customers. Also, bugfixes will be subject to internal release process constraints, so last-minute changes simply won't be going in unless they're showstoppers. However, I think that by doing this, we'll have a couple groups inside SGI, and the open source community, pounding on the same body of XFS code, which should be good. I hope to get the packages out early next week, with further explanation of what's going on. I think this plan will make the most sense in an age where we now have XFS in the core kernels from kernel.org. -Eric On Fri, 26 Mar 2004, Jan-Frode Myklebust wrote: > Are there any plans for updated kernel-rpms? Especially a version for > RHEL-3 would be much appreciated. The testing/RHEL-version didn't > boot on my systems (because of root on LVM, or maybe problems with > devfs?), so I had to revert to ext3 on the latest fileserver I set up :( > > > -jf > From owner-linux-xfs@oss.sgi.com Fri Mar 26 08:30:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 08:30:47 -0800 (PST) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [80.190.100.240]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2QGUgKO014898 for ; Fri, 26 Mar 2004 08:30:43 -0800 Received: from localhost (localhost [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id 5B89B103306 for ; Fri, 26 Mar 2004 17:30:41 +0100 (CET) Received: from nx-01.sapienti-sat.org (pD9E7E35B.dip.t-dialin.net [217.231.227.91]) by batleth.sapienti-sat.org (Postfix) with ESMTP id 256B110276F for ; Fri, 26 Mar 2004 17:30:41 +0100 (CET) Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by nx-01.sapienti-sat.org (Postfix) with SMTP id 6650A1B02D for ; Fri, 26 Mar 2004 17:30:39 +0100 (CET) Received: from koschikode.com (kaplah.sapienti-sat.org [192.168.200.15]) by nx-01.sapienti-sat.org (Postfix) with ESMTP id 455F01B02C for ; Fri, 26 Mar 2004 17:30:39 +0100 (CET) Message-ID: <40645AAE.3010001@koschikode.com> Date: Fri, 26 Mar 2004 17:30:38 +0100 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en, de-DE MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Error compiling xfsprogs-2.6.8 on Fedora Core 1 with 2.6.5-rc2-mm3 References: <20040326155304.GA21284@outblaze.com> In-Reply-To: <20040326155304.GA21284@outblaze.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2636 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs Content-Length: 611 Lines: 19 Yusuf Goolamabbas wrote: > I have 2.6.5-rc2-mm3 running on Fedora Core 1 and have xfsprogs-2.5.6 > installed on that box, I just download xfsprogs-2.6.8 and got the > following error whilst trying to compile it > > === io === > gcc -O1 -g -DDEBUG -funsigned-char -Wall -I../include > -DVERSION=\"2.6.8\" > -DLOCALEDIR=\"/usr/local/site/xfsprogs/share/locale\" > -DPACKAGE=\"xfsprogs\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 > -DHAVE_FADVISE -c -o command.o command.c > command.c:36:16: io.h: No such file or directory Same here on a RH 7.3 box with 2.4.25. xfsprogs-2.6.3 builds fine, though. Regards, Juri From owner-linux-xfs@oss.sgi.com Fri Mar 26 09:15:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 09:15:10 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2QHF3KO016604 for ; Fri, 26 Mar 2004 09:15:04 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2QI46iQ006396 for ; Fri, 26 Mar 2004 10:04:06 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2QH2VKe35898132; Fri, 26 Mar 2004 11:02:31 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i2QH2VEq3362533; Fri, 26 Mar 2004 11:02:31 -0600 (CST) Subject: Re: Error compiling xfsprogs-2.6.8 on Fedora Core 1 with 2.6.5-rc2-mm3 From: Eric Sandeen To: Yusuf Goolamabbas Cc: linux-xfs@oss.sgi.com In-Reply-To: <20040326155304.GA21284@outblaze.com> References: <20040326155304.GA21284@outblaze.com> Content-type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1080320550.17998.10.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 26 Mar 2004 11:02:31 -0600 Content-Transfer-Encoding: 8bit X-archive-position: 2637 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1266 Lines: 30 That's a new file, let me take a look. Probably needs to be added to some manifest or other in our "interesting" rpm build scheme... -Eric On Fri, 2004-03-26 at 09:53, Yusuf Goolamabbas wrote: > I have 2.6.5-rc2-mm3 running on Fedora Core 1 and have xfsprogs-2.5.6 > installed on that box, I just download xfsprogs-2.6.8 and got the > following error whilst trying to compile it > > === io === > gcc -O1 -g -DDEBUG -funsigned-char -Wall -I../include > -DVERSION=\"2.6.8\" > -DLOCALEDIR=\"/usr/local/site/xfsprogs/share/locale\" > -DPACKAGE=\"xfsprogs\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 > -DHAVE_FADVISE -c -o command.o command.c > command.c:36:16: io.h: No such file or directory > command.c: In function `command': > command.c:79: error: `file' undeclared (first use in this function) > command.c:79: error: (Each undeclared identifier is reported only once > command.c:79: error: for each function it appears in.) > command.c:83: error: `mapping' undeclared (first use in this function) > command.c:88: error: `IO_FOREIGN' undeclared (first use in this > function) > make[1]: *** [command.o] Error 1 > make: *** [default] Error 2 -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Mar 26 10:14:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 10:14:50 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2QIEhKO018540 for ; Fri, 26 Mar 2004 10:14:45 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2QJCJiQ010387 for ; Fri, 26 Mar 2004 11:12:19 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2QIAiKe35699267; Fri, 26 Mar 2004 12:10:44 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i2QIAhEq3359641; Fri, 26 Mar 2004 12:10:43 -0600 (CST) Subject: Re: Error compiling xfsprogs-2.6.8 on Fedora Core 1 with 2.6.5-rc2-mm3 From: Eric Sandeen To: Yusuf Goolamabbas Cc: linux-xfs@oss.sgi.com In-Reply-To: <1080320550.17998.10.camel@stout.americas.sgi.com> References: <20040326155304.GA21284@outblaze.com> <1080320550.17998.10.camel@stout.americas.sgi.com> Content-type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1080324643.17998.12.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 26 Mar 2004 12:10:43 -0600 Content-Transfer-Encoding: 8bit X-archive-position: 2638 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 170 Lines: 8 Fixed packages are on oss now (2.6.9) -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Mar 26 11:20:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 11:21:07 -0800 (PST) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.227]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2QJKwKO021253 for ; Fri, 26 Mar 2004 11:20:59 -0800 Received: by heretic.physik.fu-berlin.de (8.12.10/8.12.10) with ESMTP id i2QJKn6d010810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Mar 2004 20:20:53 +0100 Received: (from thimm@localhost) by neu.nirvana (8.12.10/8.12.10/Submit) id i2QJKk6L019331; Fri, 26 Mar 2004 20:20:46 +0100 Date: Fri, 26 Mar 2004 20:20:46 +0100 From: Axel Thimm To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Updated userspace on oss.sgi.com Message-ID: <20040326192046.GA19075@neu.nirvana> References: Mime-Version: 1.0 Content-type: text/plain Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Content-Transfer-Encoding: 8bit X-archive-position: 2639 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@ATrpms.net Precedence: bulk X-list: linux-xfs Content-Length: 737 Lines: 27 Hi Eric, On Fri, Mar 26, 2004 at 08:45:30AM -0600, Eric Sandeen wrote: > Hi Gang - > > Just a note, I've rebuilt all userspace packages (and created new > tarballs) from CVS and placed them at > ftp://oss.sgi.com/projects/xfs/cmd_rpms > ftp://oss.sgi.com/projects/xfs/cmd_tars you forgot to bump up the dmapi version. While it's only an autoconf update (2.53 -> 2.57), versioning should be unique :) I'll be crafting rpms for the Red Hat consumer line soon. -- Axel.Thimm at ATrpms.net -- Attached file included as plaintext by Ecartis -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAZIKOQBVS1GOamfERAg1uAKCWXRNf62P8zrJjCChfcmG+pKeCxgCcDnBK Bsh5Wcz6AiqFKk4isbq/9yc= =1Tff -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Mar 26 11:33:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 11:33:33 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2QJXTKO022325 for ; Fri, 26 Mar 2004 11:33:29 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2QJXTBB022320 for linux-xfs@oss.sgi.com; Fri, 26 Mar 2004 11:33:29 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2QJXRKQ022303 for ; Fri, 26 Mar 2004 11:33:27 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2QIeTBs019713; Fri, 26 Mar 2004 10:40:29 -0800 Date: Fri, 26 Mar 2004 10:40:29 -0800 Message-Id: <200403261840.i2QIeTBs019713@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 322] xfs internal error X-Bugzilla-Reason: AssignedTo X-archive-position: 2640 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 380 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=322 ------- Additional Comments From cw@f00f.org 2004-26-03 10:40 PDT ------- What version of gcc? Do you still get these problems when using a kernel from oss.sgi.com (CVS) built using a known-safe gcc? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Mar 26 12:07:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 12:07:29 -0800 (PST) Received: from saytrin.hq.k1024.org ([62.217.245.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2QK6mKO024236 for ; Fri, 26 Mar 2004 12:07:10 -0800 Received: by saytrin.hq.k1024.org (Postfix, from userid 4004) id BDE54367; Fri, 26 Mar 2004 22:06:32 +0200 (EET) Date: Fri, 26 Mar 2004 22:06:32 +0200 From: Iustin Pop To: roberto@redix.it Cc: Greg Koch , linux-xfs@oss.sgi.com Subject: Re: losing disk space Message-ID: <20040326200632.GA5423@saytrin.hq.k1024.org> Mail-Followup-To: roberto@redix.it, Greg Koch , linux-xfs@oss.sgi.com References: <20040325014100.0aaedcea.gkoch@tampabay.rr.com> <44293.81.72.169.49.1080228772.squirrel@mail.redix.it> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44293.81.72.169.49.1080228772.squirrel@mail.redix.it> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.5.1+cvs20040105i Content-Transfer-Encoding: 8bit X-archive-position: 2641 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs Content-Length: 688 Lines: 18 On Thu, Mar 25, 2004 at 04:32:52PM +0100, roberto@redix.it wrote: > > while du-sch / reports another. The value du give stays pretty much > > steady while the value df gives shows a gradual loss of disk space. > > > Maybe the problem is related to some process(es) that do not close a file > descriptor (a previously opened file), and a user or another precess has > removed the file. > As far I know "df" shows the free space with the "opened" but deleted > file, du shows the free space). More exactly, do a: lsof +L1 and see if any /var/log/ files show up in this - it lists files deleted but still in use - for those Unix won't free space until after they are closed. Iustin Pop From owner-linux-xfs@oss.sgi.com Fri Mar 26 15:53:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 15:53:36 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2QNrXKO003059 for ; Fri, 26 Mar 2004 15:53:33 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2R0t2iQ029914 for ; Fri, 26 Mar 2004 16:55:03 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA23359; Sat, 27 Mar 2004 10:53:21 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2QNrIFx631272; Sat, 27 Mar 2004 10:53:18 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2QNrHN0716562; Sat, 27 Mar 2004 10:53:17 +1100 (EST) Date: Sat, 27 Mar 2004 10:53:16 +1100 From: Nathan Scott To: Eric Sandeen Cc: Yusuf Goolamabbas , linux-xfs@oss.sgi.com Subject: Re: Error compiling xfsprogs-2.6.8 on Fedora Core 1 with 2.6.5-rc2-mm3 Message-ID: <20040327105316.A710085@wobbly.melbourne.sgi.com> References: <20040326155304.GA21284@outblaze.com> <1080320550.17998.10.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1080320550.17998.10.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Fri, Mar 26, 2004 at 11:02:31AM -0600 Content-Transfer-Encoding: 8bit X-archive-position: 2642 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 272 Lines: 12 On Fri, Mar 26, 2004 at 11:02:31AM -0600, Eric Sandeen wrote: > That's a new file, let me take a look. Probably needs to be added to Oh, I've botched a Makefile. Fix coming shortly. > some manifest or other in our "interesting" rpm build scheme... mhmm. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Mar 26 16:02:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 16:02:07 -0800 (PST) Received: from jdc.local (ppp1FAC.dsl.pacific.net.au [203.100.245.172]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2R021KO003656 for ; Fri, 26 Mar 2004 16:02:04 -0800 Received: from jdc.local (localhost [127.0.0.1]) by jdc.local (8.12.11/8.12.11/Debian-1) with ESMTP id i2R01ieb010709; Sat, 27 Mar 2004 11:01:49 +1100 Received: (from jason@localhost) by jdc.local (8.12.11/8.12.11/Debian-1) id i2R01cI2010681; Sat, 27 Mar 2004 11:01:38 +1100 From: Jason White MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Message-ID: <16484.50274.645339.623409@jdc.local> Date: Sat, 27 Mar 2004 11:01:38 +1100 To: Iustin Pop Cc: roberto@redix.it, Greg Koch , linux-xfs@oss.sgi.com Subject: open unlinked logs (was Re: losing disk space) In-Reply-To: <20040326200632.GA5423@saytrin.hq.k1024.org> References: <20040325014100.0aaedcea.gkoch@tampabay.rr.com> <44293.81.72.169.49.1080228772.squirrel@mail.redix.it> <20040326200632.GA5423@saytrin.hq.k1024.org> X-Mailer: VM 7.18 under Emacs 21.3.1 Reply-To: jasonw@ariel.ucs.unimelb.edu.au X-archive-position: 2643 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonw@ariel.ucs.unimelb.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 1083 Lines: 28 Iustin Pop writes: > > More exactly, do a: > lsof +L1 > and see if any /var/log/ files show up in this - it lists files deleted > but still in use - for those Unix won't free space until after they are > closed. Could this be responsive for the unlinked inode of a cups log file that I recovered, and reported on the list, a few weeks ago? Running the above command today I find: lsof +L1 COMMAND PID USER FD TYPE DEVICE SIZE NLINK NODE NAME cupsd 380 root 1u REG 3,5 7250 0 71364886 /var/log/cups/error_log.1 (deleted) What's the exact sequence of events leading to filesystem corruption? 1. File is open and written to. 2. File is unlinked while open. 3. File is closed (unlinked inodes?) 4. Alternatively, system crash before close (unlinked inodes?). Is this entirely a userspace problem (i.e., files shouldn't be unlinked while open) or is it a Linux or XFS bug? I would say anything resulting in unlinked inodes requiring recovery should be prevented at the operating system level, if possible, unless there are good reasons to the contrary. From owner-linux-xfs@oss.sgi.com Fri Mar 26 18:45:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 18:45:14 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2R2jAKO018707 for ; Fri, 26 Mar 2004 18:45:11 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2R4mR6v015689 for ; Fri, 26 Mar 2004 20:48:27 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2R2j4Ke35981898 for ; Fri, 26 Mar 2004 20:45:04 -0600 (CST) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i2R2j3Xa2296490; Fri, 26 Mar 2004 20:45:03 -0600 (CST) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id i2R2gn8D030696; Fri, 26 Mar 2004 20:42:50 -0600 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id i2R2gnU5030694; Fri, 26 Mar 2004 20:42:49 -0600 Date: Fri, 26 Mar 2004 20:42:49 -0600 From: Eric Sandeen Message-Id: <200403270242.i2R2gnU5030694@penguin.americas.sgi.com> Subject: TAKE 907752 - Fix xfsprogs source packaging X-archive-position: 2644 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 487 Lines: 23 Fix packaging issue for source packages; missing header file Date: Fri Mar 26 18:44:30 PST 2004 Workarea: penguin.americas.sgi.com:/src/eric/xfs-cmds Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:169187a xfsprogs/VERSION - 1.103 - Bump version xfsprogs/doc/CHANGES - 1.140 xfsprogs/debian/changelog - 1.93 - Doc changes xfsprogs/io/Makefile - 1.6 - Add io/io.h to list of files to package From owner-linux-xfs@oss.sgi.com Fri Mar 26 18:56:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 18:56:44 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2R2udKO019322 for ; Fri, 26 Mar 2004 18:56:39 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2R2uYf0019588 for ; Fri, 26 Mar 2004 20:56:34 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2R2uXKe35550810; Fri, 26 Mar 2004 20:56:33 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i2R2uXEr3410028; Fri, 26 Mar 2004 20:56:33 -0600 (CST) Date: Fri, 26 Mar 2004 20:56:32 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jason White cc: Iustin Pop , , Greg Koch , Subject: Re: open unlinked logs (was Re: losing disk space) In-Reply-To: <16484.50274.645339.623409@jdc.local> Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2645 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1453 Lines: 40 nothing wrong with unlinking open files, they just hang around to some extent until they're closed. I don't think it's anything to worry about, although it might be odd that something is holding it open after deletion for a very long time... What is pid 380? -Eric On Sat, 27 Mar 2004, Jason White wrote: > Iustin Pop writes: > > > > More exactly, do a: > > lsof +L1 > > and see if any /var/log/ files show up in this - it lists files deleted > > but still in use - for those Unix won't free space until after they are > > closed. > > Could this be responsive for the unlinked inode of a cups log file > that I recovered, and reported on the list, a few weeks ago? Running > the above command today I find: > lsof +L1 > COMMAND PID USER FD TYPE DEVICE SIZE NLINK NODE NAME > cupsd 380 root 1u REG 3,5 7250 0 71364886 /var/log/cups/error_log.1 (deleted) > > What's the exact sequence of events leading to filesystem corruption? > > 1. File is open and written to. > 2. File is unlinked while open. > 3. File is closed (unlinked inodes?) > 4. Alternatively, system crash before close (unlinked inodes?). > > Is this entirely a userspace problem (i.e., files shouldn't be > unlinked while open) or is it a Linux or XFS bug? I would say anything > resulting in unlinked inodes requiring recovery should be prevented at > the operating system level, if possible, unless there are good reasons > to the contrary. > > From owner-linux-xfs@oss.sgi.com Fri Mar 26 19:53:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Mar 2004 19:53:28 -0800 (PST) Received: from jdc.local (ppp1FAC.dsl.pacific.net.au [203.100.245.172]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2R3qiKO021123 for ; Fri, 26 Mar 2004 19:53:00 -0800 Received: from jdc.local (localhost [127.0.0.1]) by jdc.local (8.12.11/8.12.11/Debian-1) with ESMTP id i2R3qZNr015524 for ; Sat, 27 Mar 2004 14:52:35 +1100 Received: (from jason@localhost) by jdc.local (8.12.11/8.12.11/Debian-1) id i2R3qZtE015513; Sat, 27 Mar 2004 14:52:35 +1100 From: Jason White MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Message-ID: <16484.64131.419542.242209@jdc.local> Date: Sat, 27 Mar 2004 14:52:35 +1100 To: linux-xfs Subject: Re: open unlinked logs (was Re: losing disk space) In-Reply-To: References: <16484.50274.645339.623409@jdc.local> X-Mailer: VM 7.18 under Emacs 21.3.1 Reply-To: jasonw@ariel.ucs.unimelb.edu.au X-archive-position: 2646 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonw@ariel.ucs.unimelb.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 817 Lines: 19 Eric Sandeen writes: > nothing wrong with unlinking open files, they just hang > around to some extent until they're closed. I don't think > it's anything to worry about, although it might be odd that > something is holding it open after deletion for a very long > time... What is pid 380? cupsd I just thought that as what xfs_repair recovered a few weeks ago was also a cups log file that there might be a connection between log files' being held open after deletion, and the disconnected inode on that occasion (xfs_repair was run after a power failure and after xfs recovery). From the original report by Greg Koch it appears there were disconnected inodes in that case too, though we don't know yet whether files were being held open after unlinking. There might be nothing in any of this, of course. From owner-linux-xfs@oss.sgi.com Sat Mar 27 01:33:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 27 Mar 2004 01:33:53 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2R9XWKO004430 for ; Sat, 27 Mar 2004 01:33:32 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2R9XWCY004429 for linux-xfs@oss.sgi.com; Sat, 27 Mar 2004 01:33:32 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2R9XUKQ004415 for ; Sat, 27 Mar 2004 01:33:30 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2R9GYOu004001; Sat, 27 Mar 2004 01:16:34 -0800 Date: Sat, 27 Mar 2004 01:16:34 -0800 Message-Id: <200403270916.i2R9GYOu004001@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 322] xfs internal error X-Bugzilla-Reason: AssignedTo X-archive-position: 2648 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1943 Lines: 47 http://oss.sgi.com/bugzilla/show_bug.cgi?id=322 rutger@artibit.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER ------- Additional Comments From rutger@artibit.com 2004-27-03 01:16 PDT ------- The error messages are hard to reproduce; they only occured once (in a row), using kernel 2.6.4. I haven't tried a kernel from CVS; the gcc in question is marked as "stable" on several distributions (see info below). I will wait and see if it occurs again. $ gcc -v Reading specs from /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/specs Configured with: /var/tmp/portage/gcc-3.3.3/work/gcc-3.3.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/3.3 --includedir=/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.3/info --enable-shared --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-system-zlib --enable-languages=c,c++,f77,objc,java --enable-threads=posix --enable-long-long --disable-checking --enable-cstdio=stdio --enable-clocale=generic --enable-__cxa_atexit --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/include/g++-v3 --with-local-prefix=/usr/local --enable-shared --enable-nls --without-included-gettext --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-interpreter --enable-java-awt=xlib --with-x --disable-multilib Thread model: posix gcc version 3.3.3 20040217 (Gentoo Linux 3.3.3, propolice-3.3-7) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Mar 28 17:38:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 28 Mar 2004 17:38:27 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2T1cMKO013967 for ; Sun, 28 Mar 2004 17:38:22 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2T3ft9Q001172 for ; Sun, 28 Mar 2004 19:41:56 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2T1c5AL29552781; Mon, 29 Mar 2004 11:38:05 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2T1c2Hv25692317; Mon, 29 Mar 2004 11:38:02 +1000 (EST) Date: Mon, 29 Mar 2004 11:38:02 +1000 (EST) From: Nathan Scott Message-Id: <200403290138.i2T1c2Hv25692317@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Cc: agruen@suse.de Subject: TAKE 911982 - attr flags fix X-archive-position: 2649 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 369 Lines: 14 Fix shortform attr flags botch affecting listxattr - found and fixed by Andreas Gruenbacher. Date: Sun Mar 28 17:36:21 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux Inspected by: agruen@suse.de The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:169199a xfs_attr_leaf.c - 1.78 From owner-linux-xfs@oss.sgi.com Sun Mar 28 17:54:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 28 Mar 2004 17:54:19 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2T1sHKO014684 for ; Sun, 28 Mar 2004 17:54:17 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2T2pAiQ029269 for ; Sun, 28 Mar 2004 18:51:11 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2T1nBAL28717132; Mon, 29 Mar 2004 11:49:11 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2T1nAWW23724676; Mon, 29 Mar 2004 11:49:10 +1000 (EST) Date: Mon, 29 Mar 2004 11:49:10 +1000 (EST) From: Nathan Scott Message-Id: <200403290149.i2T1nAWW23724676@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 911984 - fix logbufs option check X-archive-position: 2650 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 348 Lines: 13 Disallow logbufs=0 unless the correct compilation flags used, else we panic. Date: Sun Mar 28 17:48:32 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux Inspected by: tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:169200a xfs_vfsops.c - 1.447 From owner-linux-xfs@oss.sgi.com Sun Mar 28 21:31:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 28 Mar 2004 21:31:08 -0800 (PST) Received: from vcgwp1.bit-drive.ne.jp (vcgwp1.bit-drive.ne.jp [211.9.32.211]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2T5V4KO025089 for ; Sun, 28 Mar 2004 21:31:05 -0800 Received: (qmail 22235 invoked from network); 29 Mar 2004 14:31:03 +0900 Received: from unknown (HELO dns01.miraclelinux.com) (219.118.163.66) by vcgwp1.bit-drive.ne.jp with SMTP; 29 Mar 2004 14:31:03 +0900 Received: from miraclelinux.com (dhcp-0139.miraclelinux.com [10.1.0.139]) by dns01.miraclelinux.com (8.9.3+3.2W/3.7W/03090111) with ESMTP id OAA28858; Mon, 29 Mar 2004 14:31:03 +0900 Message-ID: <4067B496.8060501@miraclelinux.com> Date: Mon, 29 Mar 2004 14:31:02 +0900 From: "IKARASHI, Seiichi" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: Stefan Smietanowski CC: Steve Lord , Christoph Hellwig , Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> <20040325124152.GA12078@dingdong.cryptoapps.com> <4062D7E5.6070501@stesmi.com> <20040325132200.GA12333@dingdong.cryptoapps.com> <4062E19A.90207@xfs.org> <20040325140723.GA12558@dingdong.cryptoapps.com> <20040325144519.A23764@infradead.org> <40635F04.6010109@xfs.org> <40636032.3000402@stesmi.com> <4063612E.4030109@xfs.org> <406361F2.6060308@stesmi.com> <4063650B.20600@xfs.org> <406365DE.2050006@stesmi.com> In-Reply-To: <406365DE.2050006@stesmi.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2651 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ikarashi@miraclelinux.com Precedence: bulk X-list: linux-xfs Content-Length: 704 Lines: 26 Hello, Stefan Smietanowski wrote: > Hi Steve. > >> Try this for an experiment, before the run, set >> >> /proc/sys/fs/xfs/sync_interval >> >> down to some small number like 1000, pause for a couple >> of seconds after calling sync, and then see if grub >> can see the files via the block device. >> >> This tunable controls how long xfs delays writing out >> inodes into the metadata cache from their internal format. > > > Alright. I'll try that on my DVD in a few hours and get back to you. How was this testing result? I suppose setting sync_interval to 1000 and sleeping 2 seconds after sync is basically same as sleeping 4 seconds or more with the default sync_interval value (3000?). Seiich From owner-linux-xfs@oss.sgi.com Sun Mar 28 22:32:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 28 Mar 2004 22:32:16 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2T6WBKO027325 for ; Sun, 28 Mar 2004 22:32:12 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2T6Jof0006805 for ; Mon, 29 Mar 2004 00:19:54 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i2T6JYAL29567383; Mon, 29 Mar 2004 16:19:34 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i2T6JWY829743355; Mon, 29 Mar 2004 16:19:32 +1000 (EST) Date: Mon, 29 Mar 2004 16:19:32 +1000 (EST) From: Nathan Scott Message-Id: <200403290619.i2T6JWY829743355@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 911981 - superblock flushing X-archive-position: 2652 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 370 Lines: 13 Ensure sb not flushed async on a SYNC_WAIT sync. Fixed by Bart Samwel. Date: Sun Mar 28 22:18:02 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux Inspected by: lord@xfs.org,hch@lst.de,bart@samwel.tk The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:169208a xfs_vfsops.c - 1.448 From owner-linux-xfs@oss.sgi.com Sun Mar 28 22:33:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 28 Mar 2004 22:33:41 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2T6XdKO027579 for ; Sun, 28 Mar 2004 22:33:39 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2T6Xd9P027578 for linux-xfs@oss.sgi.com; Sun, 28 Mar 2004 22:33:39 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2T6XbKS027559 for ; Sun, 28 Mar 2004 22:33:37 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2T5caZD025676; Sun, 28 Mar 2004 21:38:36 -0800 Date: Sun, 28 Mar 2004 21:38:36 -0800 Message-Id: <200403290538.i2T5caZD025676@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 321] XFS internal error, xfs_force_shutdown on 1.2TB fileserver. X-Bugzilla-Reason: AssignedTo X-archive-position: 2653 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 403 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=321 cchan@outblaze.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cchan@outblaze.com ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Mar 28 23:27:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 28 Mar 2004 23:27:38 -0800 (PST) Received: from finnpos.fi (pc1-1692.finnpos.fi [212.246.250.178] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2T7RWKO029762 for ; Sun, 28 Mar 2004 23:27:34 -0800 Received: from ([192.168.169.118]) by finnpos.fi (Merak 4.10.050) with SMTP id ACB36977 for ; Mon, 29 Mar 2004 11:21:40 +0300 From: "Leo Hynninen" To: linux-xfs@oss.sgi.com Date: Mon, 29 Mar 2004 10:25:00 +0300 MIME-Version: 1.0 Subject: xfs/serial timeout (cc[vtime]) Message-ID: <4067F97C.4567.70357C@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-description: Mail message body X-archive-position: 2654 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: leo.hynninen@finnpos.fi Precedence: bulk X-list: linux-xfs Content-Length: 471 Lines: 17 Hello We have slackware 9.0 patched with patch from slackware cd. If I boot the kernel on ext2 filesystems I will have serialport timeout but if I boot up with xfs disk I dont get timeout at all? I dont know is this right place to ask this. Linux Slackware 9.0 i386 40GB hard disk 128MT ram I try with few motherboard but no different(Intel and Asrock) I try to get timeout from usbtoserial boxes as well but there is not different. Thank you. -Piki pikix@suomi24.fi From owner-linux-xfs@oss.sgi.com Mon Mar 29 05:23:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Mar 2004 05:23:03 -0800 (PST) Received: from relay03.roc.ny.frontiernet.net (relay03.roc.ny.frontiernet.net [66.133.131.36]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2TDMxKO017570 for ; Mon, 29 Mar 2004 05:22:59 -0800 Received: (qmail 20062 invoked from network); 29 Mar 2004 13:22:57 -0000 Received: from 208-186-10-249.nrp1.brv.mn.frontiernet.net (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay03.roc.ny.frontiernet.net (FrontierMTA 2.3.18) with SMTP for ; 29 Mar 2004 13:22:57 -0000 Message-ID: <40682301.50508@xfs.org> Date: Mon, 29 Mar 2004 07:22:09 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "IKARASHI, Seiichi" CC: Stefan Smietanowski , Christoph Hellwig , Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> <20040325124152.GA12078@dingdong.cryptoapps.com> <4062D7E5.6070501@stesmi.com> <20040325132200.GA12333@dingdong.cryptoapps.com> <4062E19A.90207@xfs.org> <20040325140723.GA12558@dingdong.cryptoapps.com> <20040325144519.A23764@infradead.org> <40635F04.6010109@xfs.org> <40636032.3000402@stesmi.com> <4063612E.4030109@xfs.org> <406361F2.6060308@stesmi.com> <4063650B.20600@xfs.org> <406365DE.2050006@stesmi.com> <4067B496.8060501@miraclelinux.com> In-Reply-To: <4067B496.8060501@miraclelinux.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2655 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 341 Lines: 16 IKARASHI, Seiichi wrote: > > How was this testing result? > I suppose setting sync_interval to 1000 and sleeping 2 seconds > after sync is basically same as sleeping 4 seconds or more with > the default sync_interval value (3000?). > > Seiich > Except the default setting is 30000 or 30 seconds. I have not heard back from Stefan. Steve From owner-linux-xfs@oss.sgi.com Mon Mar 29 05:48:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Mar 2004 05:48:14 -0800 (PST) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.227]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2TDm8KO018646 for ; Mon, 29 Mar 2004 05:48:09 -0800 Received: by heretic.physik.fu-berlin.de (8.12.10/8.12.10) with ESMTP id i2TDm2R6027676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Mar 2004 15:48:03 +0200 Received: (from thimm@localhost) by neu.nirvana (8.12.10/8.12.10/Submit) id i2TDm0s1008664; Mon, 29 Mar 2004 15:48:00 +0200 Date: Mon, 29 Mar 2004 15:47:59 +0200 From: Axel Thimm To: linux-xfs@oss.sgi.com Cc: Bent.Terp@biosci.ki.se Subject: getxattr over NFS returns EIO instead of EOPNOTSUPP Message-ID: <20040329134759.GA8624@neu.nirvana> Mime-Version: 1.0 Content-type: text/plain Content-Disposition: inline User-Agent: Mutt/1.4.2i Content-Transfer-Encoding: 8bit X-archive-position: 2656 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@ATrpms.net Precedence: bulk X-list: linux-xfs Content-Length: 557 Lines: 23 Hi, please have a look at the following bug report: http://bugzilla.atrpms.net/show_bug.cgi?id=73 getxattr returns I/O error when the NFS server is not serving EA/ACLs. Previous kernels return "not supported". The difference are XFS 1.3.0 patches and the nfs-acl patches. Thanks. -- Axel.Thimm at ATrpms.net -- Attached file included as plaintext by Ecartis -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAaCkPQBVS1GOamfERAu4BAJoD+hhaKR/C8Flxe1Aftyn836CFVwCeIBP4 CDQpfMsRjwM4yguBl14H910= =3dei -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Mon Mar 29 07:38:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Mar 2004 07:38:50 -0800 (PST) Received: from 2003SERVER.sbs2003.local (host213-123-250-229.in-addr.btopenworld.com [213.123.250.229]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2TFcRKO022476 for ; Mon, 29 Mar 2004 07:38:41 -0800 Received: from mail pickup service by 2003SERVER.sbs2003.local with Microsoft SMTPSVC; Mon, 29 Mar 2004 16:39:14 +0100 thread-index: AcQVo/uYgQCtENrWS2yHzbE7zVQqcw== X-From_: linux-kernel-owner+paul=40sumlocktest.fsnet.co.uk@vger.kernel.org Fri Jan 02 20:34:07 2004 Envelope-to: paul@sumlocktest.fsnet.co.uk Delivery-date: Fri, 02 Jan 2004 20:34:07 +0000 Message-ID: <005201c415a3$fb982040$d100000a@sbs2003.local> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4+dev To: Cc: , Subject: Re: XFS forced shutdown with kernel 2.6.0 In-Reply-To: Your message of "Fri, 02 Jan 2004 18:29:21 GMT." <20040102182921.A27237@infradead.org> From: References: <20040102095051.GA19872@rootdir.de> <20040102182921.A27237@infradead.org> MIME-Version: 1.0 Content-Class: urn:content-classes:message Importance: normal Content-type: text/plain Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-Transfer-Encoding: 8bit Date: Mon, 29 Mar 2004 16:39:11 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-OriginalArrivalTime: 29 Mar 2004 15:39:14.0828 (UTC) FILETIME=[FD6454C0:01C415A3] X-archive-position: 2657 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Valdis.Kletnieks@vt.edu Precedence: bulk X-list: linux-xfs Content-Length: 1710 Lines: 49 On Fri, 02 Jan 2004 18:29:21 GMT, Christoph Hellwig said: > I've seen the same bug a few times lately, but only if I had previous > memory corruption due to code I was hacking on. Can you reproduce it > without the nvidia module loaded as that is likely source of such > corruption? While you're at it, see what *else* you can turn off - RAID, devfs, NFS, etc. It's equally likely that you're tripping over some other kernel module's use-after-free or chase-the-wrong-pointer bug. I've seen a lot more bugfixes for *those* on this list than cases where "I turned off nvidia and it started working". From the 2.6.1-rc1 release notes: Jeff Garzik: o [libata] fix use-after-free Stephen Hemminger: o [ROSE]: Fix use after free in socket destruction Andrew Morton, on broken iee1394: > aargh, sorry. You need to revert > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1-rc1/2.6.1-rc1-mm1/broken-out/sysfs-add-vc-class.patch > > This is the totally weird tty oops which Greg and I have been starting > at bemusedly for a few days. That's *this week* or so. Yes, I understand the political and/or realistic reasons for refusing to look at tainted kernels, but let's face it guys, *our* code is to blame more often than NVidia's. When was the last time there was a *verified* report of "I turned the NVidia graphics module off and things worked" that wasn't directly related to a graphics issue? -- Attached file included as plaintext by Ecartis -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE/9dQ8cC3lWbTT17ARArKIAJ9DhuID6a64NS2C4syITqd0pPVr4QCfXlNZ tdIH3vQ1sJnWfWhZCl7/KV0= =Ji3J -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Mon Mar 29 07:43:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Mar 2004 07:43:29 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2TFhQKO022958 for ; Mon, 29 Mar 2004 07:43:26 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1B7yv6-0003tZ-H2; Mon, 29 Mar 2004 16:43:24 +0100 Date: Mon, 29 Mar 2004 16:43:24 +0100 From: Christoph Hellwig To: Axel Thimm Cc: linux-xfs@oss.sgi.com, Bent.Terp@biosci.ki.se Subject: Re: getxattr over NFS returns EIO instead of EOPNOTSUPP Message-ID: <20040329164324.A14946@infradead.org> References: <20040329134759.GA8624@neu.nirvana> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040329134759.GA8624@neu.nirvana>; from Axel.Thimm@ATrpms.net on Mon, Mar 29, 2004 at 03:47:59PM +0200 Content-Transfer-Encoding: 8bit X-archive-position: 2658 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 585 Lines: 14 On Mon, Mar 29, 2004 at 03:47:59PM +0200, Axel Thimm wrote: > Hi, > please have a look at the following bug report: > http://bugzilla.atrpms.net/show_bug.cgi?id=73 > > getxattr returns I/O error when the NFS server is not serving > EA/ACLs. Previous kernels return "not supported". The difference are > XFS 1.3.0 patches and the nfs-acl patches. I don't see how this is XFS-related. fs/xattr.c is in mainline now and always returned EOPNOTSUPP if xattrs are not implemented in the actual filesystem. My guess is that the nfs-acl patches have some bugs, what about asking Andreas? From owner-linux-xfs@oss.sgi.com Mon Mar 29 07:49:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Mar 2004 07:49:27 -0800 (PST) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2TFnNKO023564 for ; Mon, 29 Mar 2004 07:49:25 -0800 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i2TFnDId011904; Mon, 29 Mar 2004 17:49:13 +0200 Message-ID: <40684573.5010002@stesmi.com> Date: Mon, 29 Mar 2004 17:49:07 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord CC: "IKARASHI, Seiichi" , Christoph Hellwig , Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> <20040325124152.GA12078@dingdong.cryptoapps.com> <4062D7E5.6070501@stesmi.com> <20040325132200.GA12333@dingdong.cryptoapps.com> <4062E19A.90207@xfs.org> <20040325140723.GA12558@dingdong.cryptoapps.com> <20040325144519.A23764@infradead.org> <40635F04.6010109@xfs.org> <40636032.3000402@stesmi.com> <4063612E.4030109@xfs.org> <406361F2.6060308@stesmi.com> <4063650B.20600@xfs.org> <406365DE.2050006@stesmi.com> <4067B496.8060501@miraclelinux.com> <40682301.50508@xfs.org> In-Reply-To: <40682301.50508@xfs.org> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2659 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 475 Lines: 24 Steve Lord wrote: > IKARASHI, Seiichi wrote: > >> >> How was this testing result? >> I suppose setting sync_interval to 1000 and sleeping 2 seconds >> after sync is basically same as sleeping 4 seconds or more with >> the default sync_interval value (3000?). >> >> Seiich >> > Except the default setting is 30000 or 30 seconds. > > I have not heard back from Stefan. > > Steve Been a bit busy and the one I built had a *Groan* typo ... Rebuilding it now... // Stefan From owner-linux-xfs@oss.sgi.com Mon Mar 29 08:00:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Mar 2004 08:00:35 -0800 (PST) Received: from 2003SERVER.sbs2003.local (host213-123-250-229.in-addr.btopenworld.com [213.123.250.229]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2TG09KO024158 for ; Mon, 29 Mar 2004 08:00:30 -0800 Received: from mail pickup service by 2003SERVER.sbs2003.local with Microsoft SMTPSVC; Mon, 29 Mar 2004 16:46:37 +0100 X-Sieve: Server Sieve 2.2 Message-ID: <04a601c415a5$0513b020$d100000a@sbs2003.local> thread-index: AcQVo/uYgQCtENrWS2yHzbE7zVQqcw== X-From_: linux-kernel-owner+paul=40sumlocktest.fsnet.co.uk@vger.kernel.org Fri Jan 02 20:34:07 2004 Delivery-date: Fri, 02 Jan 2004 20:34:07 +0000 X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4+dev To: Cc: , Subject: Re: XFS forced shutdown with kernel 2.6.0 In-Reply-To: Your message of "Fri, 02 Jan 2004 18:29:21 GMT." <20040102182921.A27237@infradead.org> From: References: <20040102095051.GA19872@rootdir.de> <20040102182921.A27237@infradead.org> MIME-Version: 1.0 Content-Class: urn:content-classes:message Importance: normal Content-type: text/plain; charset=iso-8859-1 Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-Transfer-Encoding: 8bit Date: Mon, 29 Mar 2004 16:46:37 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-OriginalArrivalTime: 29 Mar 2004 15:39:14.0828 (UTC) FILETIME=[FD6454C0:01C415A3] X-archive-position: 2657 X-ecartis-version: Ecartis v1.0.0 X-original-sender: Valdis.Kletnieks@vt.edu Precedence: bulk X-list: linux-xfs X-archive-position: 2660 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Valdis.Kletnieks@vt.edu Precedence: bulk X-list: linux-xfs Content-Length: 1714 Lines: 52 On Fri, 02 Jan 2004 18:29:21 GMT, Christoph Hellwig said: > I've seen the same bug a few times lately, but only if I had previous > memory corruption due to code I was hacking on. Can you reproduce it > without the nvidia module loaded as that is likely source of such > corruption? While you're at it, see what *else* you can turn off - RAID, devfs, NFS, etc. It's equally likely that you're tripping over some other kernel module's use-after-free or chase-the-wrong-pointer bug. I've seen a lot more bugfixes for *those* on this list than cases where "I turned off nvidia and it started working". From the 2.6.1-rc1 release notes: Jeff Garzik: o [libata] fix use-after-free Stephen Hemminger: o [ROSE]: Fix use after free in socket destruction Andrew Morton, on broken iee1394: > aargh, sorry. You need to revert > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1-rc1/2.6.1-rc1-mm1/broken-out/sysfs-add-vc-class.patch > > This is the totally weird tty oops which Greg and I have been starting > at bemusedly for a few days. That's *this week* or so. Yes, I understand the political and/or realistic reasons for refusing to look at tainted kernels, but let's face it guys, *our* code is to blame more often than NVidia's. When was the last time there was a *verified* report of "I turned the NVidia graphics module off and things worked" that wasn't directly related to a graphics issue? -- Attached file included as plaintext by Ecartis -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE/9dQ8cC3lWbTT17ARArKIAJ9DhuID6a64NS2C4syITqd0pPVr4QCfXlNZ tdIH3vQ1sJnWfWhZCl7/KV0= =Ji3J -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Mon Mar 29 08:05:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Mar 2004 08:05:37 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2TG5HKO024965 for ; Mon, 29 Mar 2004 08:05:18 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1B7zGF-0003xB-QY; Mon, 29 Mar 2004 17:05:15 +0100 Date: Mon, 29 Mar 2004 17:05:15 +0100 From: Christoph Hellwig To: Valdis.Kletnieks@vt.edu Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS forced shutdown with kernel 2.6.0 Message-ID: <20040329170515.A15175@infradead.org> Mail-Followup-To: Christoph Hellwig , Valdis.Kletnieks@vt.edu, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20040102095051.GA19872@rootdir.de> <20040102182921.A27237@infradead.org> <04a601c415a5$0513b020$d100000a@sbs2003.local> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <04a601c415a5$0513b020$d100000a@sbs2003.local>; from Valdis.Kletnieks@vt.edu on Mon, Mar 29, 2004 at 04:46:37PM +0100 Content-Transfer-Encoding: 8bit X-archive-position: 2661 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 224 Lines: 6 Could you please stop the bitching? If you want your collection of assorted buggy free and non-free kernel configs supported buy a support contract from someone who's interested in providing such support for you. *plonk* From owner-linux-xfs@oss.sgi.com Mon Mar 29 08:21:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Mar 2004 08:21:48 -0800 (PST) Received: from 2003SERVER.sbs2003.local (host213-123-250-229.in-addr.btopenworld.com [213.123.250.229]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2TGLEKS028684 for ; Mon, 29 Mar 2004 08:21:41 -0800 Received: from mail pickup service by 2003SERVER.sbs2003.local with Microsoft SMTPSVC; Mon, 29 Mar 2004 16:39:15 +0100 thread-index: AcQVo/uvqTutLrj8T2Ocs8UreyUd9g== X-From_: linux-kernel-owner+paul=40sumlocktest.fsnet.co.uk@vger.kernel.org Fri Jan 02 20:37:53 2004 Envelope-to: paul@sumlocktest.fsnet.co.uk Delivery-date: Fri, 02 Jan 2004 20:37:53 +0000 Message-ID: <006201c415a3$fbafee00$d100000a@sbs2003.local> Content-Transfer-Encoding: 8bit Date: Mon, 29 Mar 2004 16:39:11 +0100 From: "Christoph Hellwig" To: Cc: "Claas Langbehn" , , X-Mailer: Microsoft CDO for Exchange 2000 Subject: Re: XFS forced shutdown with kernel 2.6.0 Mail-Followup-To: Christoph Hellwig ,Valdis.Kletnieks@vt.edu, Claas Langbehn ,linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20040102095051.GA19872@rootdir.de> <20040102182921.A27237@infradead.org> <200401022027.i02KRe7X013502@turing-police.cc.vt.edu> MIME-Version: 1.0 Content-Class: urn:content-classes:message Content-type: text/plain; charset=us-ascii Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200401022027.i02KRe7X013502@turing-police.cc.vt.edu>; from Valdis.Kletnieks@vt.edu on Fri, Jan 02, 2004 at 03:27:40PM -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-OriginalArrivalTime: 29 Mar 2004 15:39:15.0828 (UTC) FILETIME=[FDFCEB40:01C415A3] X-archive-position: 2663 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 1049 Lines: 26 On Fri, Jan 02, 2004 at 03:27:40PM -0500, Valdis.Kletnieks@vt.edu wrote: > On Fri, 02 Jan 2004 18:29:21 GMT, Christoph Hellwig said: > > > I've seen the same bug a few times lately, but only if I had previous > > memory corruption due to code I was hacking on. Can you reproduce it > > without the nvidia module loaded as that is likely source of such > > corruption? > > While you're at it, see what *else* you can turn off - RAID, devfs, NFS, etc. > > It's equally likely that you're tripping over some other kernel module's > use-after-free or chase-the-wrong-pointer bug. I've seen a lot more bugfixes > for *those* on this list than cases where "I turned off nvidia and it started > working". The difference is that I can look at those while I can't look at nvidias driver. Pretty simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-xfs@oss.sgi.com Mon Mar 29 08:21:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Mar 2004 08:21:30 -0800 (PST) Received: from 2003SERVER.sbs2003.local (host213-123-250-229.in-addr.btopenworld.com [213.123.250.229]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2TGLEKO028684 for ; Mon, 29 Mar 2004 08:21:23 -0800 Received: from mail pickup service by 2003SERVER.sbs2003.local with Microsoft SMTPSVC; Mon, 29 Mar 2004 16:39:03 +0100 thread-index: AcQVo/WDgEeTCXBXQ6eqJB0lFv9N2A== X-From_: linux-kernel-owner+paul=40sumlocktest.fsnet.co.uk@vger.kernel.org Fri Jan 02 18:31:38 2004 Envelope-to: paul@sumlocktest.fsnet.co.uk Delivery-date: Fri, 02 Jan 2004 18:31:38 +0000 Message-ID: <003701c415a3$f585b690$d100000a@sbs2003.local> Date: Mon, 29 Mar 2004 16:39:01 +0100 Content-Transfer-Encoding: 8bit From: "Christoph Hellwig" To: Cc: , Subject: Re: XFS forced shutdown with kernel 2.6.0 X-Mailer: Microsoft CDO for Exchange 2000 Mail-Followup-To: Christoph Hellwig ,Claas Langbehn , linux-kernel@vger.kernel.org,linux-xfs@oss.sgi.com References: <20040102095051.GA19872@rootdir.de> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Content-Class: urn:content-classes:message Importance: normal User-Agent: Mutt/1.2.5.1i Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 In-Reply-To: <20040102095051.GA19872@rootdir.de>; from claas@rootdir.de on Fri, Jan 02, 2004 at 10:50:51AM +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-OriginalArrivalTime: 29 Mar 2004 15:39:03.0078 (UTC) FILETIME=[F6636C60:01C415A3] X-archive-position: 2662 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 1088 Lines: 33 On Fri, Jan 02, 2004 at 10:50:51AM +0100, Claas Langbehn wrote: > Hello! > > > Last night one of my machines running xfs shut down my /homes partition. > > That machine was running Azureus (a bittorrent client) with probably > high memory usage. > > But even if the memory usage of one program is going near to 100% it > should not force the filesystem to shutdown. Instead it should crash > the application. > > I could also think of bad memory, but we did test the SDRAM modules > only a week ago, and they passed memtest86. > > After rebooting everything was working fine, again. > > So, is this a bug of xfs? I've seen the same bug a few times lately, but only if I had previous memory corruption due to code I was hacking on. Can you reproduce it without the nvidia module loaded as that is likely source of such corruption? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-xfs@oss.sgi.com Mon Mar 29 09:20:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Mar 2004 09:20:57 -0800 (PST) Received: from ms-smtp-03.tampabay.rr.com (ms-smtp-03-smtplb.tampabay.rr.com [65.32.5.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2THKrKO001761 for ; Mon, 29 Mar 2004 09:20:53 -0800 Received: from lexx.gnuorder.net (653250hfc18.tampabay.rr.com [65.32.50.18]) by ms-smtp-03.tampabay.rr.com (8.12.10/8.12.7) with SMTP id i2THKouI026488 for ; Mon, 29 Mar 2004 12:20:51 -0500 (EST) Date: Mon, 29 Mar 2004 12:20:49 -0500 From: Greg Koch To: linux-xfs@oss.sgi.com Subject: Re: losing disk space Message-Id: <20040329122049.50b2dc74.gkoch@tampabay.rr.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-archive-position: 2664 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gkoch@tampabay.rr.com Precedence: bulk X-list: linux-xfs Content-Length: 1221 Lines: 35 On Thu, Mar 25, 2004 at 04:32:52PM +0100, roberto@redix.it wrote: > > > while du-sch / reports another. The value du give stays pretty > >much > > > steady while the value df gives shows a gradual loss of disk > > > > space. > > > > > Maybe the problem is related to some process(es) that do not close a > > file descriptor (a previously opened file), and a user or another > > precess has removed the file. > > As far I know "df" shows the free space with the "opened" but > > > deleted > > file, du shows the free space). > > More exactly, do a: > lsof +L1 > and see if any /var/log/ files show up in this - it lists files deleted > but still in use - for those Unix won't free space until after they are > closed. > > Iustin Pop Thanks, that's exactly what is happening. I have apache using a gracefull restart and a delay before closing the files but that isn't enough it seems. I will increase the delay for now and look into using piped logging. In the mean time, is there a way to close these files once deleted? -- My colleagues, every statement I make today is backed up by sources, solid sources. These are not assertions. What we are giving you are facts and conclusions based on solid intelligence. From owner-linux-xfs@oss.sgi.com Mon Mar 29 11:56:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Mar 2004 11:56:28 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2TJuQKO009607 for ; Mon, 29 Mar 2004 11:56:26 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i2TM07IC017072 for ; Mon, 29 Mar 2004 14:00:07 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i2TJuJKe36046968; Mon, 29 Mar 2004 13:56:19 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1B82rq-0001ZB-00; Mon, 29 Mar 2004 13:56:18 -0600 Subject: PARTIAL TAKE 908809 - pagebuf Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Mon, 29 Mar 2004 13:56:18 -0600 X-archive-position: 2665 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 701 Lines: 25 Date: Mon Mar 29 11:55:10 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:169276a fs/xfs/xfsidbg.c - 1.258 - cleanup pagebuf flag usage and simplify pagebuf_free fs/xfs/linux-2.6/xfs_buf.h - 1.94 - cleanup pagebuf flag usage and simplify pagebuf_free fs/xfs/linux-2.6/xfs_buf.c - 1.161 - cleanup pagebuf flag usage and simplify pagebuf_free fs/xfs/linux-2.4/xfs_buf.h - 1.100 - cleanup pagebuf flag usage and simplify pagebuf_free fs/xfs/linux-2.4/xfs_buf.c - 1.182 - cleanup pagebuf flag usage and simplify pagebuf_free From owner-linux-xfs@oss.sgi.com Mon Mar 29 15:02:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Mar 2004 15:02:58 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2TN2tKO022150 for ; Mon, 29 Mar 2004 15:02:55 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 7B2F7FB839; Mon, 29 Mar 2004 17:02:53 -0600 (CST) Date: Mon, 29 Mar 2004 15:02:53 -0800 From: Chris Wedgwood To: Greg Koch Cc: linux-xfs@oss.sgi.com Subject: Re: losing disk space Message-ID: <20040329230253.GA22318@dingdong.cryptoapps.com> References: <20040329122049.50b2dc74.gkoch@tampabay.rr.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040329122049.50b2dc74.gkoch@tampabay.rr.com> Content-Transfer-Encoding: 8bit X-archive-position: 2666 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 540 Lines: 15 On Mon, Mar 29, 2004 at 12:20:49PM -0500, Greg Koch wrote: > Thanks, that's exactly what is happening. I have apache using a > gracefull restart and a delay before closing the files but that > isn't enough it seems. I will increase the delay for now and look > into using piped logging. In the mean time, is there a way to close > these files once deleted? Apache needs to close them. Either restart apache or perhaps you can send it a signal to have it reopen it's log files. A google search seems to indicate a HUP will do this. From owner-linux-xfs@oss.sgi.com Mon Mar 29 15:05:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Mar 2004 15:05:41 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2TN5cKO022574 for ; Mon, 29 Mar 2004 15:05:38 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 524D1FB839; Mon, 29 Mar 2004 17:05:37 -0600 (CST) Date: Mon, 29 Mar 2004 15:05:37 -0800 From: Chris Wedgwood To: Leo Hynninen Cc: linux-xfs@oss.sgi.com Subject: Re: xfs/serial timeout (cc[vtime]) Message-ID: <20040329230537.GB22318@dingdong.cryptoapps.com> References: <4067F97C.4567.70357C@localhost> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4067F97C.4567.70357C@localhost> Content-Transfer-Encoding: 8bit X-archive-position: 2667 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 313 Lines: 13 On Mon, Mar 29, 2004 at 10:25:00AM +0300, Leo Hynninen wrote: > If I boot the kernel on ext2 filesystems I will have serialport > timeout but if I boot up with xfs disk I dont get timeout at all? > > I dont know is this right place to ask this. Not really. Try slackware support and forums perhaps. --cw From owner-linux-xfs@oss.sgi.com Mon Mar 29 15:50:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Mar 2004 15:50:40 -0800 (PST) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2TNoaKO025142 for ; Mon, 29 Mar 2004 15:50:37 -0800 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i2TNoPId031563; Tue, 30 Mar 2004 01:50:25 +0200 Message-ID: <4068B63A.5030104@stesmi.com> Date: Tue, 30 Mar 2004 01:50:18 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Smietanowski CC: Steve Lord , "IKARASHI, Seiichi" , Christoph Hellwig , Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> <20040325124152.GA12078@dingdong.cryptoapps.com> <4062D7E5.6070501@stesmi.com> <20040325132200.GA12333@dingdong.cryptoapps.com> <4062E19A.90207@xfs.org> <20040325140723.GA12558@dingdong.cryptoapps.com> <20040325144519.A23764@infradead.org> <40635F04.6010109@xfs.org> <40636032.3000402@stesmi.com> <4063612E.4030109@xfs.org> <406361F2.6060308@stesmi.com> <4063650B.20600@xfs.org> <406365DE.2050006@stesmi.com> <4067B496.8060501@miraclelinux.com> <40682301.50508@xfs.org> <40684573.5010002@stesmi.com> In-Reply-To: <40684573.5010002@stesmi.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2668 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 638 Lines: 34 Stefan Smietanowski wrote: > Steve Lord wrote: > > >>IKARASHI, Seiichi wrote: >> >> >>>How was this testing result? >>>I suppose setting sync_interval to 1000 and sleeping 2 seconds >>>after sync is basically same as sleeping 4 seconds or more with >>>the default sync_interval value (3000?). >>> >>>Seiich >>> >> >>Except the default setting is 30000 or 30 seconds. >> >>I have not heard back from Stefan. >> >>Steve > > > Been a bit busy and the one I built had a *Groan* typo ... > > Rebuilding it now... > > // Stefan Oh yes. The mobo that I build the distro on just fried so there will be more delays. Sorry guys // Stefan From owner-linux-xfs@oss.sgi.com Mon Mar 29 19:16:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Mar 2004 19:16:48 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2U3GiKO003048 for ; Mon, 29 Mar 2004 19:16:44 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2U4IZiQ018557 for ; Mon, 29 Mar 2004 20:18:36 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA10519; Tue, 30 Mar 2004 13:16:30 +1000 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i2U3GTmX032048; Tue, 30 Mar 2004 13:16:30 +1000 Received: (from tes@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i2U3GSKU032046; Tue, 30 Mar 2004 13:16:28 +1000 Date: Tue, 30 Mar 2004 13:16:28 +1000 From: Tim Shimmin Message-Id: <200403300316.i2U3GSKU032046@sherman.melbourne.sgi.com> Subject: TAKE 910634 - xfs_iaccess changes Apparently-To: Apparently-To: X-archive-position: 2669 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 583 Lines: 21 Do fix as suggested in: http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-10/6030.html and prompted for by Andreas G. --Tim Date: Mon Mar 29 19:11:23 PST 2004 Workarea: sherman.melbourne.sgi.com:/build/tes/isms/2.4.x-xfs Inspected by: nathans@sgi.com,agruen@suse.de The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:169300a fs/xfs/xfs_inode.c - 1.395 - Modify xfs_iaccess() for CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH. This makes the access checks like the other linux fs's for CAP_DAC in this area. From owner-linux-xfs@oss.sgi.com Mon Mar 29 19:33:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Mar 2004 19:33:45 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2U3XhKO004141 for ; Mon, 29 Mar 2004 19:33:43 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2U3XhXq004140 for linux-xfs@oss.sgi.com; Mon, 29 Mar 2004 19:33:43 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i2U3XfKU004120 for ; Mon, 29 Mar 2004 19:33:42 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i2U3KnOe003538; Mon, 29 Mar 2004 19:20:49 -0800 Date: Mon, 29 Mar 2004 19:20:49 -0800 Message-Id: <200403300320.i2U3KnOe003538@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 321] XFS internal error, xfs_force_shutdown on 1.2TB fileserver. X-Bugzilla-Reason: AssignedTo X-archive-position: 2670 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 401 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=321 kent@outblaze.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kent@outblaze.com ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Mar 29 21:02:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Mar 2004 21:02:43 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2U52dKO010100 for ; Mon, 29 Mar 2004 21:02:39 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2U4oxf0008375 for ; Mon, 29 Mar 2004 22:51:00 -0600 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA11632; Tue, 30 Mar 2004 14:50:55 +1000 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i2U4otmX032209; Tue, 30 Mar 2004 14:50:55 +1000 Received: (from tes@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i2U4os42032207; Tue, 30 Mar 2004 14:50:54 +1000 Date: Tue, 30 Mar 2004 14:50:54 +1000 From: Tim Shimmin Message-Id: <200403300450.i2U4os42032207@sherman.melbourne.sgi.com> Subject: TAKE 911223 - add v2 stripe size for reservation Apparently-To: Apparently-To: X-archive-position: 2671 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 763 Lines: 28 TODO: want to add in more space tracing... --Tim Date: Mon Mar 29 20:49:15 PST 2004 Workarea: sherman.melbourne.sgi.com:/build/tes/isms/2.4.x-xfs-test Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:169304a fs/xfs/xfs_log.c - 1.292 - try to be more explicit in adding in the non-transactional data to the reservation estimate. We must add in for the worst case of a log stripe taking us the full distance for a log stripe boundary. fs/xfs/xfs_macros.c - 1.55 - remove xlog_btolrbb() which has changed and is only needed in one place. fs/xfs/xfs_log_priv.h - 1.101 - remove xlog_btolrbb() which has changed and is only needed in one place. From owner-linux-xfs@oss.sgi.com Mon Mar 29 23:54:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Mar 2004 23:54:23 -0800 (PST) Received: from gold.csi.cam.ac.uk (gold.csi.cam.ac.uk [131.111.8.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2U7sIKO014941 for ; Mon, 29 Mar 2004 23:54:19 -0800 Received: from tanzanite.trinhall.cam.ac.uk ([131.111.228.184] helo=tanzanite) by gold.csi.cam.ac.uk with esmtp (Exim 4.20) id 1B7cI4-0007ap-7y; Sun, 28 Mar 2004 16:33:36 +0100 From: Jeff Snyder To: Avtar Gill Subject: Re: Your post on the linux-xfs mailing list Date: Sun, 28 Mar 2004 15:33:02 +0000 User-Agent: KMail/1.6 Cc: linux-xfs@oss.sgi.com References: <406687F1.9040008@sympatico.ca> In-Reply-To: <406687F1.9040008@sympatico.ca> MIME-Version: 1.0 Content-Disposition: inline Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <200403281633.02800.jeff@caffeinated.me.uk> X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-archive-position: 2672 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jeff@caffeinated.me.uk Precedence: bulk X-list: linux-xfs Content-Length: 1057 Lines: 26 Hi Avtar, On Sunday 28 March 2004 09:08, Avtar Gill wrote: > Hi I'm curious to know if you're issues with XFS + EVMS & LVM on > a RAID 1 array were solved after your last post to the mailing > list. I will have a similar set up so I'd appreciate it if you > could share the rest of your experience. Thanks. after my posts on the xfs mailing list, I had my xfs filesystems in a usable state. It has however taken me a week of recompiling stuff (gentoo) to recover from the filesystem damage :( Right now i'm back to running one disk, so I dont know if I'll have the same problems when I next try to expand my raid onto the second disk, but I'll let you know when I do. I'll probably sync the disks manually before letting evms near it, as a safety measure next time. However, If you're in a situation to set up evms with raid1 accross both disks from the start, then do that. It's what I did on my debian server and that's worked wonderfully (just read the install guide and make sure you have the raid1 patch if neccecary!) :D Cheers, Jeff From owner-linux-xfs@oss.sgi.com Tue Mar 30 01:55:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Mar 2004 01:55:28 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2U9tPKO021375 for ; Tue, 30 Mar 2004 01:55:26 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 3DD17FB839; Tue, 30 Mar 2004 03:55:25 -0600 (CST) Date: Tue, 30 Mar 2004 01:55:25 -0800 From: Chris Wedgwood To: Jeff Snyder Cc: Avtar Gill , linux-xfs@oss.sgi.com Subject: Re: Your post on the linux-xfs mailing list Message-ID: <20040330095525.GA27109@dingdong.cryptoapps.com> References: <406687F1.9040008@sympatico.ca> <200403281633.02800.jeff@caffeinated.me.uk> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403281633.02800.jeff@caffeinated.me.uk> Content-Transfer-Encoding: 8bit X-archive-position: 2673 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 963 Lines: 25 On Sun, Mar 28, 2004 at 03:33:02PM +0000, Jeff Snyder wrote: > after my posts on the xfs mailing list, I had my xfs filesystems in > a usable state. It has however taken me a week of recompiling stuff > (gentoo) to recover from the filesystem damage :( gentoo... sigh > Right now i'm back to running one disk, so I dont know if I'll have > the same problems when I next try to expand my raid onto the second > disk, but I'll let you know when I do. I'll probably sync the disks > manually before letting evms near it, as a safety measure next time. there is a correlation between filesystem corruption and other problems and gentoo... go figure.. a distro where it seems any old patch is thown into the kernel based upon how cool it is rather then the quality of the code, important other patches are ignored and where using the latest bleeding edge userspace (including gcc) seems to be common... who would ever think that might casue problems? --cw From owner-linux-xfs@oss.sgi.com Tue Mar 30 20:51:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Mar 2004 20:51:38 -0800 (PST) Received: from hermod.acsalaska.net (hermod.acsalaska.net [209.112.155.45]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2V4pUKO002501 for ; Tue, 30 Mar 2004 20:51:31 -0800 Received: from erbenson.alaska.net (74-pm18.nwc.acsalaska.net [209.112.142.74]) by hermod.acsalaska.net (8.12.11/8.12.11) with ESMTP id i2V4pOkr045652 for ; Tue, 30 Mar 2004 19:51:25 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id E5CB739E7 for ; Tue, 30 Mar 2004 19:51:21 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 3325640FF35; Tue, 30 Mar 2004 19:51:22 -0900 (AKST) Date: Tue, 30 Mar 2004 19:51:22 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Your post on the linux-xfs mailing list Message-ID: <20040331045122.GB21226@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <406687F1.9040008@sympatico.ca> <200403281633.02800.jeff@caffeinated.me.uk> <20040330095525.GA27109@dingdong.cryptoapps.com> Mime-Version: 1.0 Content-type: text/plain Content-Disposition: inline In-Reply-To: <20040330095525.GA27109@dingdong.cryptoapps.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.38; SA 2.63; spamdefang 1.93 Content-Transfer-Encoding: 8bit X-archive-position: 2674 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 2004 Lines: 50 On Tue, Mar 30, 2004 at 01:55:25AM -0800, Chris Wedgwood wrote: > On Sun, Mar 28, 2004 at 03:33:02PM +0000, Jeff Snyder wrote: > > > after my posts on the xfs mailing list, I had my xfs filesystems in > > a usable state. It has however taken me a week of recompiling stuff > > (gentoo) to recover from the filesystem damage :( > > gentoo... sigh the `took a week to recompile, and thus recover everything' is nothing more then the fault of the user for choosing the greatest timewaster distro of all, and for not making backups. [*] > > Right now i'm back to running one disk, so I dont know if I'll have > > the same problems when I next try to expand my raid onto the second > > disk, but I'll let you know when I do. I'll probably sync the disks > > manually before letting evms near it, as a safety measure next time. > > there is a correlation between filesystem corruption and other > problems and gentoo... > > go figure.. a distro where it seems any old patch is thown into the > kernel based upon how cool it is rather then the quality of the code, > important other patches are ignored and where using the latest > bleeding edge userspace (including gcc) seems to be common... who > would ever think that might casue problems? the anti-gentoo cabal, of course. [*] normally not backing system binary files is not so terrible since you can reinstall the system quite rapidly, only configuration and user data need be backed up, gentoo of course changes that, replacing any significant system binary can be extremely time consuming (far far beyond the time to download a binary), therefore gentoo systems must be fully backed up, which means you need a whole lot more backup tapes. -- Ethan Benson http://www.alaska.net/~erbenson/ -- Attached file included as plaintext by Ecartis -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkBqTkkACgkQJKx7GixEevzmgQCffeb1iuSz6Bh4RbKrHWPQY0ME QNcAn2Hhtj30rBo4kXtFCi43E552rSk9 =G9Vw -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Tue Mar 30 22:43:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Mar 2004 22:43:34 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2V6hWKO006557 for ; Tue, 30 Mar 2004 22:43:32 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2V7jSiQ016004 for ; Tue, 30 Mar 2004 23:45:31 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA08215; Wed, 31 Mar 2004 16:43:14 +1000 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i2V6hDmX012186; Wed, 31 Mar 2004 16:43:13 +1000 Received: (from tes@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i2V6h9os012184; Wed, 31 Mar 2004 16:43:09 +1000 Date: Wed, 31 Mar 2004 16:43:09 +1000 From: Tim Shimmin Message-Id: <200403310643.i2V6h9os012184@sherman.melbourne.sgi.com> Subject: PARTIAL TAKE 912078 - fix invutil for segfault due to sprintf Apparently-To: Apparently-To: X-archive-position: 2675 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 560 Lines: 20 update invutil for correct string length and to use snprintf (bugzilla#320) Date: Tue Mar 30 22:40:45 PST 2004 Workarea: sherman.melbourne.sgi.com:/build/tes/isms/xfs-cmds Inspected by: alkirkco@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:169384a xfsdump/VERSION - 1.60 xfsdump/doc/CHANGES - 1.67 xfsdump/invutil/invutil.c - 1.15 xfsdump/invutil/stobj.c - 1.6 xfsdump/invutil/screen.c - 1.5 xfsdump/invutil/menu.c - 1.5 xfsdump/invutil/fstab.c - 1.5 xfsdump/invutil/invidx.c - 1.5 From owner-linux-xfs@oss.sgi.com Tue Mar 30 22:50:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Mar 2004 22:50:56 -0800 (PST) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.227]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2V6opKO007122 for ; Tue, 30 Mar 2004 22:50:51 -0800 Received: by heretic.physik.fu-berlin.de (8.12.10/8.12.10) with ESMTP id i2V6ogR6026602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Mar 2004 08:50:43 +0200 Received: (from thimm@localhost) by neu.nirvana (8.12.10/8.12.10/Submit) id i2V6ofCg014961; Wed, 31 Mar 2004 08:50:41 +0200 Date: Wed, 31 Mar 2004 08:50:41 +0200 From: Axel Thimm To: acl-devel@bestbits.at Cc: linux-xfs@oss.sgi.com, Bent.Terp@biosci.ki.se Subject: Re: getxattr over NFS returns EIO instead of EOPNOTSUPP Message-ID: <20040331065041.GD12450@neu.nirvana> Reply-To: acl-devel@bestbits.at, Bent.Terp@biosci.ki.se Mail-Followup-To: acl-devel@bestbits.at, Bent.Terp@biosci.ki.se References: <20040329134759.GA8624@neu.nirvana> <20040329164324.A14946@infradead.org> Mime-Version: 1.0 Content-type: text/plain Content-Disposition: inline In-Reply-To: <20040329164324.A14946@infradead.org> User-Agent: Mutt/1.4.2i Content-Transfer-Encoding: 8bit X-archive-position: 2676 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@ATrpms.net Precedence: bulk X-list: linux-xfs Content-Length: 1142 Lines: 30 On Mon, Mar 29, 2004 at 04:43:24PM +0100, Christoph Hellwig wrote: > On Mon, Mar 29, 2004 at 03:47:59PM +0200, Axel Thimm wrote: > > please have a look at the following bug report: > > http://bugzilla.atrpms.net/show_bug.cgi?id=73 > > > > getxattr returns I/O error when the NFS server is not serving > > EA/ACLs. Previous kernels return "not supported". The difference are > > XFS 1.3.0 patches and the nfs-acl patches. > > I don't see how this is XFS-related. fs/xattr.c is in mainline now > and always returned EOPNOTSUPP if xattrs are not implemented in the > actual filesystem. My guess is that the nfs-acl patches have some > bugs, what about asking Andreas? OK, moving the thread over to acl-devel. I assume the XFS patches and the nfs-acl patches are not doing well, at least on the Fedora Core patched kernel. That's why I tried at linux-xfs list first. -- Axel.Thimm at ATrpms.net -- Attached file included as plaintext by Ecartis -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAampBQBVS1GOamfERAlfSAJ9fn4DD9VWRnzUkTpCYy23MaYdJNwCeNwMv LqQ/4vm2ZLIFOLIFb88ENTs= =SXWj -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Mar 31 01:01:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Mar 2004 01:01:56 -0800 (PST) Received: from meel.hobby.nl (meel.hobby.nl [212.72.224.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2V91cKO014886 for ; Wed, 31 Mar 2004 01:01:41 -0800 Received: from ics.snow.nl (ics.snow.nl [212.72.238.14]) by meel.hobby.nl (8.12.10/8.12.9) with ESMTP id i2V91UWi005708 for ; Wed, 31 Mar 2004 11:01:31 +0200 (CEST) (envelope-from daniel@snow.nl) Received: from scn-lan43.snowcn.snow.nl (scn-lan43.snowcn.snow.nl [10.9.8.63]) by ics.snow.nl (Postfix) with ESMTP id 9369C2126BF for ; Wed, 31 Mar 2004 11:00:43 +0200 (CEST) Subject: old xfsprogs tarbals From: Daniel van Eeden To: linux-xfs@oss.sgi.com Content-type: text/plain Organization: Snow B.V. Message-Id: <1080723666.8003.12.camel@daniel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 31 Mar 2004 11:01:07 +0200 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new X-archive-position: 2677 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: daniel@snow.nl Precedence: bulk X-list: linux-xfs Content-Length: 325 Lines: 8 I'm maintaining a source based linux distribution which uses XFS as default filesystem. The buildscripts usualy use the official tarbals from the official locations. That's not posible with xfsprogs and such. The old tarbals seem to disapear, which is against the (L)GPL as far as I know. Daniel van Eeden From owner-linux-xfs@oss.sgi.com Wed Mar 31 02:14:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Mar 2004 02:14:59 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2VAElKO018118 for ; Wed, 31 Mar 2004 02:14:47 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 0138EFB839; Wed, 31 Mar 2004 04:14:42 -0600 (CST) Date: Wed, 31 Mar 2004 02:14:42 -0800 From: Chris Wedgwood To: Daniel van Eeden Cc: linux-xfs@oss.sgi.com Subject: Re: old xfsprogs tarbals Message-ID: <20040331101442.GA6648@dingdong.cryptoapps.com> References: <1080723666.8003.12.camel@daniel> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1080723666.8003.12.camel@daniel> Content-Transfer-Encoding: 8bit X-archive-position: 2678 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 433 Lines: 15 On Wed, Mar 31, 2004 at 11:01:07AM +0200, Daniel van Eeden wrote: > I'm maintaining a source based linux distribution which uses XFS as > default filesystem. The buildscripts usualy use the official tarbals > from the official locations. That's not posible with xfsprogs and > such. Can the scripts not cvs checkout the required files? > The old tarbals seem to disapear, which is against the (L)GPL as far > as I know. Is it? From owner-linux-xfs@oss.sgi.com Wed Mar 31 07:17:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Mar 2004 07:17:28 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2VFHOKO002908 for ; Wed, 31 Mar 2004 07:17:25 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1B8hT1-0002CM-6f; Wed, 31 Mar 2004 16:17:23 +0100 Date: Wed, 31 Mar 2004 16:17:23 +0100 From: Christoph Hellwig To: Daniel van Eeden Cc: linux-xfs@oss.sgi.com Subject: Re: old xfsprogs tarbals Message-ID: <20040331161723.A8418@infradead.org> References: <1080723666.8003.12.camel@daniel> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1080723666.8003.12.camel@daniel>; from daniel@snow.nl on Wed, Mar 31, 2004 at 11:01:07AM +0200 Content-Transfer-Encoding: 8bit X-archive-position: 2679 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 557 Lines: 12 On Wed, Mar 31, 2004 at 11:01:07AM +0200, Daniel van Eeden wrote: > The old tarbals seem to disapear, which is against the (L)GPL as far as > I know. That's bullshit. The GPL requires you to keep around the source _if_ you hand out binaries only with a written offer to get source later. SGI never used that GPL clause but always distributed both source adn binaries from the same place (oss.sgi.com and the SGI ProPack CDROMs). Even if SGI didn't they just have to give you the source for the old binaries but not keep them in the same place forever. From owner-linux-xfs@oss.sgi.com Wed Mar 31 09:21:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Mar 2004 09:21:58 -0800 (PST) Received: from mail.dniq-online.com (dniq-online.com [209.172.191.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2VHLkKO012010 for ; Wed, 31 Mar 2004 09:21:46 -0800 Received: from dniq-online.com (firewall.mc.net [209.172.181.98]) by mail.dniq-online.com (Postfix) with ESMTP id ABF5F21DA2C for ; Wed, 31 Mar 2004 10:54:14 -0600 (CST) Message-ID: <406AF7B6.6030405@dniq-online.com> Date: Wed, 31 Mar 2004 10:54:14 -0600 From: Dmitry Nikiforov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: file corruption Content-type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit X-archive-position: 2680 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dniq_kraft@dniq-online.com Precedence: bulk X-list: linux-xfs Content-Length: 1091 Lines: 24 Hello! I've seen some reports here about file corruption and suggestions to update XFS. I currently am running kernel 2.6.3 on my system, and virtually every time my system gets rebooted without shutdown (which happens sometime), I get corrupted files. Most often I get just random garbage _within_ a file, even though there are no complaints while checking filesystem. It happened before with earlier versions of kernel, on different computers. Currently I'm running Mandrake 10.0 on Intel platform (namely - dell dimension 4400), and at home I run the same Mandrake on AMD-64 platform, with exactly the same problem: virtually every time I get power failure or unconditional reboot for whatever reason - I get corrupted files with random garbage inside. I'm reformatting my partitions to JFS later this week, but still would like to know if there is a cure for this problem on XFS. I understand that this might well be a hardware related problem, but two different computers with the same hardware problem? I find it not very likely :) Thank you! -- Regards, DNiq. From owner-linux-xfs@oss.sgi.com Wed Mar 31 23:15:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Mar 2004 23:15:15 -0800 (PST) Received: from harmonie.imag.fr (harmonie.imag.fr [147.171.130.40]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i317FCKO030108 for ; Wed, 31 Mar 2004 23:15:13 -0800 Received: from mail-veri.imag.fr (pave.imag.fr [129.88.43.12]) by harmonie.imag.fr (8.12.10/8.12.7) with ESMTP id i317ExaH015270 for ; Thu, 1 Apr 2004 09:14:59 +0200 (CEST) Received: from obiou.imag.fr ([129.88.43.2] helo=obiou.imag.fr.imag.fr ident=kowalski) by mail-veri.imag.fr with esmtp (Exim 3.35 #1 (Debian)) id 1B8wPj-0003z8-00 for ; Thu, 01 Apr 2004 09:14:59 +0200 To: linux-xfs@oss.sgi.com Subject: Re: file corruption References: <406AF7B6.6030405@dniq-online.com> From: Nicolas Kowalski Mail-Copies-To: never Date: Thu, 01 Apr 2004 09:14:59 +0200 In-Reply-To: <406AF7B6.6030405@dniq-online.com> (Dmitry Nikiforov's message of "Wed, 31 Mar 2004 10:54:14 -0600") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information Content-Transfer-Encoding: 8bit X-archive-position: 2681 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 511 Lines: 23 Dmitry Nikiforov writes: > Hello! Hello. > I've seen some reports here about file corruption and suggestions to > update XFS. I currently am running kernel 2.6.3 on my system, and [...] This is a FAQ: http://oss.sgi.com/projects/xfs/faq.html#nulls Tip: set the synchronous updates (S) flag on the files you find damaged when an unplanned reboot happens; this is especially usefull for desktop environment config files (rewritten very frequently). Regards. -- Nicolas From owner-linux-xfs@oss.sgi.com Wed Mar 31 23:33:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Mar 2004 23:33:55 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i317XrKO031136 for ; Wed, 31 Mar 2004 23:33:53 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i317XrpN031135 for linux-xfs@oss.sgi.com; Wed, 31 Mar 2004 23:33:53 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i317XqKQ031121 for ; Wed, 31 Mar 2004 23:33:52 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3170cY6023961; Wed, 31 Mar 2004 23:00:38 -0800 Date: Wed, 31 Mar 2004 23:00:38 -0800 Message-Id: <200404010700.i3170cY6023961@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 311] ioctl hang in 2.6.x kernels with quota support X-Bugzilla-Reason: AssignedTo X-archive-position: 2682 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1124 Lines: 31 http://oss.sgi.com/bugzilla/show_bug.cgi?id=311 ------- Additional Comments From steven.wilton@team.eftel.com 2004-31-03 23:00 PDT ------- OK, I have been tring the 2.6.4 kernel on our production system, and have just got it to hang again. This time we were doing an rsync and an xfs_fsr on the same filesystem, and bot of these processe have hung. We got the following error message in the kernel log (dmesg) around the time of the hang: pagebuf_get: warning, failed to lookup pages By looking at /proc//fd for the rsync process, I managed to find the directory entry that the hung rsync process was accessing at the time. If I try and run an "ls" on that directory, the ls process also hangs. If I strace the ls process, it hangs after trying to run the following: open("", O_RDONLY|O_NONBLOCK_O_LARGEFILE,O_DIRECTORY) = 3 fstat64(3, {st_mode=S_IFDIR|0700, st_size=147456, ...}) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 getdents64(0x3, 0x8056ee0, 0x1000, 0 <-----hangs here ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.