similar to: another quota related ext3fs crash...

hiya! i'm currently running 2.4.12-ac1 w/o any further ext3 patches. i've got a dir with some fairly big files (like 15mb/file) in it and while sfv-checking these i got the following errors: Oct 14 21:47:59 srck@trottelkunde attempt to access beyond end of device Oct 14 21:47:59 srck@trottelkunde 16:42: rw=0, want=600889688, limit=12289725 Oct 14 21:47:59 srck@trottelkunde attempt to

Hi! I experienced an ext3 crash a few days ago, the corresponding part of my kernel log is attached (there were no IDE-errors, just the ext3 stuff). The /home partition (/dev/hdd2) got remounted ro, so the box was still usable somehow (was able to log in, kill stuff and reboot it). I rebooted it, it came back up again w/o any problems, remounted /home ro and did a e2fsck on it, which reported

A brand new system setup with RH 7.3 is still Oopsing after every X hours. The problem started after about 1 week without errors. Sometimes everything is locked, sometimes still messages are written to /var/log/messages. Sometimes other processes keep running (can still ping the machine) I upgraded the kernel to 2.4.18-19.7.x, changed the memory, but still got problems. When I read all sort of

One of our servers (false) just oopsed. In the middle of lunch. Any advise? On console: false kernel: Assertion failure in journal_start() at transaction.c line 245: "handle->h_transaction->t_journal == journal" In kernel log (ran it through ksymoops): Nov 13 12:35:37 false kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000 Nov 13 12:35:37

Hi, I have a server configured as follows: a standard 2.4.18 kernel, IDE discs, 1Gb RAM (not all used), load avg around 1-2. a large partition, formatted reiserfs within large partition are 80 300Mb loopback file systems, formatted ext3. I got the following assertion yesterday which forced a lot of processes into D state. I'm not sure how easy it is to reproduce this problem.

hello! i'm using redhat 7.2 with ext3 as my primary fs on kernel 2.4.17 + grsecurity + acl after 2-3 days of uptime i'm expiriencing problems... i attached below excert from my system logs. machine stops responing for a few seconds and after then it looks, like it's in normal operation again. the only problem is load, which is incrementing constantly, but cpu is 99% idle... after

hello! i'm using redhat 7.2 with ext3 as my primary fs on kernel 2.4.17 + grsecurity + acl after 2-3 days of uptime i'm expiriencing problems... i attached below excert from my system logs. machine stops responing for a few seconds and after then it looks, like it's in normal operation again. the only problem is load, which is incrementing constantly, but cpu is 99% idle...

As per ext4 specification: > In ext2, ext3, and ext4 (when the 64bit feature is not enabled), the > block group descriptor was only 32 bytes long and therefore ends at > bg_checksum. On an ext4 filesystem with the 64bit feature enabled, the > block group descriptor expands to at least the 64 bytes described below; > the size is stored in the superblock. Since block group

Hi, When trying to run a particular program, I reproducibly get a few dozen kernel messages of the form: attempt to access beyond end of device 03:06: rw=0, want=536995844, limit=11680168 attempt to access beyond end of device 03:06: rw=0, want=1342296068, limit=11680168

Hello Since 2.4.20, we have problems with ext3. Machine is 2xPentium III (1GHz), 2GB RAM, 1GB swap. RH 8.0 (glibc-2.3.1-21), gcc (GCC) 3.2 20020903 We have a lot of users: oceanic:~# wc -l /etc/passwd 6694 /etc/passwd connected via SAMBA (2.2.7) from 200-300 Windows-XX workstations Partition with ext3 looks like this: oceanic:~# mount |grep ext3 /dev/sdb5 on /home1 type ext3

The whole loop=0,1,2 thing was kind of odd and not very self explanatory. I''ve replaced it with a list_for_each_entry on space_info->block_groups. If we have a hint we just jump into the loop with the block group and start looking for space. If we don''t find anything we start at the beginning and start looking. We never come out of the loop with a ref on the block_group

Hello, So there is an odd case where we can possibly return -ENOSPC when there is in fact space to be had. I think I finally have a hold on what the problem is, it only happens with Metadata writes, and happens _very_ infrequently. What has to happen is we have to allocate have allocated out of the first logical byte on the disk, which would set last_alloc to first_logical_byte(root, 0), so

Yan Zheng hit a problem where we tried to remove some free space but failed because we couldn''t find the free space entry. This is because the free space was held within a bitmap that had a starting offset well before the actual offset of the free space, and there were free space extents that were in the same range as that offset, so tree_search_offset returned with NULL because we

If we are looking for a cluster in a particularly sparse or fragmented block group, we will do a lot of looping through the free space tree looking for various things, and if we need to look at bitmaps we will endup doing the whole dance twice. So instead add the bitmap entries to a temporary list so if we have to do the bitmap search we can just look through the list of entries we''ve

the tree log recover code expects no free space cached before it executes. Signed-off-by: Yan Zheng <zheng.yan@oracle.com> --- diff -urp 4/fs/btrfs/extent-tree.c 8/fs/btrfs/extent-tree.c --- 4/fs/btrfs/extent-tree.c 2010-05-11 14:15:29.174108554 +0800 +++ 8/fs/btrfs/extent-tree.c 2010-05-11 13:26:38.036107000 +0800 @@ -316,11 +329,6 @@ static int caching_kthread(void *data) if (!path)

I noticed a huge problem with the free space cache that was presenting as an early ENOSPC. Turns out when writing the free space cache out I forgot to take into account pinned extents and more importantly clusters. This would result in us leaking free space everytime we unmounted the filesystem and remounted it. I fix this by making sure to check and see if the current block group has a cluster

We have been using bytes_reserved for metadata reservations, which is wrong since we use that to keep track of outstanding reservations from the allocator. This resulted in us doing a lot of silly things to make sure we don''t allocate a bunch of metadata chunks since we never had a real view of how much space was actually in use by metadata. There are a lot of fixes in here to make this

We have been using bytes_reserved for metadata reservations, which is wrong since we use that to keep track of outstanding reservations from the allocator. This resulted in us doing a lot of silly things to make sure we don''t allocate a bunch of metadata chunks since we never had a real view of how much space was actually in use by metadata. There are a lot of fixes in here to make this

Hello, This patch fixes a problem where we end up seeking too much when *last_ptr is valid. This happens because btrfs_lookup_first_block_group only returns a block group that starts on or after the given search start, so if the search_start is in the middle of a block group it will return the block group after the given search_start, which is suboptimal. This patch fixes that by doing a

Hi all, It seems like memory barrier is not required in cached_block_group.I am looking at kernel 2.6.34-rc2. cache_block_group(struct btrfs_block_group_cache *cache) { smp_mb(); if (cache->cached != BTRFS_CACHE_NO) return 0; .... } This function is called from btrfs_alloc_logged_file_extent and find_free_extent. In btrfs_alloc_logged_file_extent the code snippet is as follows