attempt to access beyond end of device

attempt to access beyond end of device

[Piotr Szymaniak]

[-- Attachment #1: Type: text/plain, Size: 5007 bytes --]

Hello,

I'm running nilfs2 on Raspberry Pi and some time ago it got some
problem.

Connected the SD card to my PC today and mounted the fs, the cleaner
started and few minutes later it remounted the fs readonly. Here's the
dmesg part:

[ 1109.889697] mmcblk0: mmc0:b368 SMI   7.51 GiB 
[ 1109.891261]  mmcblk0: p1 p2 p3
[ 1129.467450] NILFS warning: mounting unchecked fs
[ 1129.956859] NILFS: recovery complete.
[ 1129.960064] segctord starting. Construction interval = 300 seconds, CP frequency < 30 seconds
[ 1129.979344] NILFS warning: mounting fs with errors
[ 1283.005874] attempt to access beyond end of device
[ 1283.005882] mmcblk0p3: rw=8192, want=145241775180196072, limit=15120384
[ 1283.005891] attempt to access beyond end of device
[ 1283.005896] mmcblk0p3: rw=8192, want=36678440, limit=15120384
[ 1283.512451] init_special_inode: bogus i_mode (160444) for inode mmcblk0p3:59824
[ 1283.667864] attempt to access beyond end of device
[ 1283.667869] mmcblk0p3: rw=8192, want=5764893396078298024, limit=15120384
[ 1284.492368] init_special_inode: bogus i_mode (4620) for inode mmcblk0p3:17013
[ 1284.707910] mmcblk0: error -110 transferring data, sector 5236904, nr 24, cmd response 0x900, card status 0xb00
[ 1284.707926] mmcblk0: retrying using single block read
[ 1284.792489] mmcblk0: error -110 transferring data, sector 5236904, nr 24, cmd response 0x900, card status 0x0
[ 1284.792498] end_request: I/O error, dev mmcblk0, sector 5236904
[ 1284.877077] mmcblk0: error -110 transferring data, sector 5236905, nr 23, cmd response 0x900, card status 0x0
[ 1284.877091] end_request: I/O error, dev mmcblk0, sector 5236905
[ 1284.961660] mmcblk0: error -110 transferring data, sector 5236906, nr 22, cmd response 0x900, card status 0x0
[ 1284.961674] end_request: I/O error, dev mmcblk0, sector 5236906
[ 1285.046235] mmcblk0: error -110 transferring data, sector 5236907, nr 21, cmd response 0x900, card status 0x0
[ 1285.046246] end_request: I/O error, dev mmcblk0, sector 5236907
[ 1285.130754] mmcblk0: error -110 transferring data, sector 5236908, nr 20, cmd response 0x900, card status 0x0
[ 1285.130764] end_request: I/O error, dev mmcblk0, sector 5236908
[ 1285.215320] mmcblk0: error -110 transferring data, sector 5236909, nr 19, cmd response 0x900, card status 0x0
[ 1285.215332] end_request: I/O error, dev mmcblk0, sector 5236909
[ 1285.299926] mmcblk0: error -110 transferring data, sector 5236910, nr 18, cmd response 0x900, card status 0x0
[ 1285.299945] end_request: I/O error, dev mmcblk0, sector 5236910
[ 1285.384537] mmcblk0: error -110 transferring data, sector 5236911, nr 17, cmd response 0x900, card status 0x0
[ 1285.384554] end_request: I/O error, dev mmcblk0, sector 5236911
[ 1285.615295] init_special_inode: bogus i_mode (2024) for inode mmcblk0p3:2218
[ 1288.601672] attempt to access beyond end of device
[ 1288.601677] mmcblk0p3: rw=8192, want=145241775180196072, limit=15120384
[ 1288.601681] attempt to access beyond end of device
[ 1288.601683] mmcblk0p3: rw=8192, want=36678440, limit=15120384
[ 1290.442474] init_special_inode: bogus i_mode (160545) for inode mmcblk0p3:59808
[ 1290.677312] attempt to access beyond end of device
[ 1290.677317] mmcblk0p3: rw=0, want=12305576757786212880, limit=15120384
[ 1290.677319] attempt to access beyond end of device
[ 1290.677321] mmcblk0p3: rw=0, want=12305576757786212880, limit=15120384
[ 1290.677324] NILFS error (device mmcblk0p3): nilfs_readdir: bad page in #38030
[ 1290.677325] Remounting filesystem read-only
[ 1290.681553] attempt to access beyond end of device
[ 1290.681557] mmcblk0p3: rw=0, want=1231588818889969824, limit=15120384
[ 1290.681559] attempt to access beyond end of device
[ 1290.681560] mmcblk0p3: rw=0, want=1231588818889969824, limit=15120384
[ 1290.681563] NILFS error (device mmcblk0p3): nilfs_readdir: bad page in #38033
[ 1290.681578] attempt to access beyond end of device
[ 1290.681579] mmcblk0p3: rw=0, want=6682469067434422488, limit=15120384
[ 1290.681581] attempt to access beyond end of device
[ 1290.681582] mmcblk0p3: rw=0, want=6682469067434422488, limit=15120384
[ 1290.681584] NILFS error (device mmcblk0p3): nilfs_readdir: bad page in #38036
[ 1290.734000] init_special_inode: bogus i_mode (1752) for inode mmcblk0p3:38170
[ 1290.736411] init_special_inode: bogus i_mode (160545) for inode mmcblk0p3:59816
[ 1290.736419] init_special_inode: bogus i_mode (1752) for inode mmcblk0p3:59818
[ 1290.736424] init_special_inode: bogus i_mode (160545) for inode mmcblk0p3:38168
[ 1291.005227] init_special_inode: bogus i_mode (50004) for inode mmcblk0p3:2042
[ 1291.013041] init_special_inode: bogus i_mode (50444) for inode mmcblk0p3:2815


Should I check the card in the first place?


Piotr Szymaniak.
-- 
<kow`> "There are 10 types of people in the world... those who
understand binary and those who don't."
<SpaceRain> That's only 2 types of people, kow.
<SpaceRain> STUPID
  -- bash.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: attempt to access beyond end of device

[Vyacheslav Dubeyko]

Hi Piotr,

On Mon, 2014-03-24 at 08:13 +0100, Piotr Szymaniak wrote:
> Hello,
> 
> I'm running nilfs2 on Raspberry Pi and some time ago it got some
> problem.
> 
> Connected the SD card to my PC today and mounted the fs, the cleaner
> started and few minutes later it remounted the fs readonly. Here's the
> dmesg part:
> 
> [ 1109.889697] mmcblk0: mmc0:b368 SMI   7.51 GiB 
> [ 1109.891261]  mmcblk0: p1 p2 p3
> [ 1129.467450] NILFS warning: mounting unchecked fs
> [ 1129.956859] NILFS: recovery complete.
> [ 1129.960064] segctord starting. Construction interval = 300 seconds, CP frequency < 30 seconds
> [ 1129.979344] NILFS warning: mounting fs with errors
> [ 1283.005874] attempt to access beyond end of device
> [ 1283.005882] mmcblk0p3: rw=8192, want=145241775180196072, limit=15120384

I see that it was requested 8 KB block. How did you create file system?
Could you share the superblock content?

> 
> Should I check the card in the first place?
> 

Currently, I suspect that you have bad SD card. But, maybe, you have
something different.

With the best regards,
Vyacheslav Dubeyko.


--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: attempt to access beyond end of device

[Piotr Szymaniak]

[-- Attachment #1.1: Type: text/plain, Size: 3110 bytes --]

On Mon, Mar 24, 2014 at 11:37:35AM +0400, Vyacheslav Dubeyko wrote:
> Hi Piotr,
> 
> On Mon, 2014-03-24 at 08:13 +0100, Piotr Szymaniak wrote:
> > Hello,
> > 
> > I'm running nilfs2 on Raspberry Pi and some time ago it got some
> > problem.
> > 
> > Connected the SD card to my PC today and mounted the fs, the cleaner
> > started and few minutes later it remounted the fs readonly. Here's the
> > dmesg part:
> > 
> > [ 1109.889697] mmcblk0: mmc0:b368 SMI   7.51 GiB 
> > [ 1109.891261]  mmcblk0: p1 p2 p3
> > [ 1129.467450] NILFS warning: mounting unchecked fs
> > [ 1129.956859] NILFS: recovery complete.
> > [ 1129.960064] segctord starting. Construction interval = 300 seconds, CP frequency < 30 seconds
> > [ 1129.979344] NILFS warning: mounting fs with errors
> > [ 1283.005874] attempt to access beyond end of device
> > [ 1283.005882] mmcblk0p3: rw=8192, want=145241775180196072, limit=15120384
> 
> I see that it was requested 8 KB block. How did you create file system?

That was some time ago, so I'm unable to answer this question. But
nilfs-tune shows 4KB blocks:

~ # nilfs-tune -l /dev/sdf3
nilfs-tune 2.1.6
Filesystem volume name:   (none)
Filesystem UUID:          53760664-f9ed-4c8d-af42-c6ee2f16d956
Filesystem magic number:  0x3434
Filesystem revision #:    2.0
Filesystem features:      (none)
Filesystem state:         invalid or mounted,error
Filesystem OS type:       Linux
Block size:               4096
Filesystem created:       Fri Aug  3 08:37:06 2012
Last mount time:          Mon Mar 24 07:55:53 2014
Last write time:          Mon Mar 24 07:58:04 2014
Mount count:              100
Maximum mount count:      50
Reserve blocks uid:       0 (user root)
Reserve blocks gid:       0 (group root)
First inode:              11
Inode size:               128
DAT entry size:           32
Checkpoint size:          192
Segment usage size:       16
Number of segments:       922
Device size:              7741636608
First data block:         1
# of blocks per segment:  2048
Reserved segments %:      5
Last checkpoint #:        770589
Last block address:       595617
Last sequence #:          41763
Free blocks count:        395264
Commit interval:          300
# of blks to create seg:  0
CRC seed:                 0x3e0bea06
CRC check sum:            0x2596b671
CRC check data size:      0x00000118



> Could you share the superblock content?

If my calculations are correct (it's the second superblock, right?), it should
be:
dd if=/dev/nilfs of=dump bs=Block size skip=Device size / Block size - 1
count=1

Attached this one.


> > Should I check the card in the first place?
> > 
> 
> Currently, I suspect that you have bad SD card. But, maybe, you have
> something different.

Maybe I will check it.


Piotr Szymaniak.
-- 
(...) wszystko to sprawilo,  iz przekroczyl owa umowna  granice,  ktora
jego przyjaciel,  prawnik Dan Tabares,  nazywal linia MTWD. Gdy raz juz
przekroczyles linie  MTWD  cokolwiek by sie zdarzylo, ty po prostu Masz
To W Dupie.
  -- Graham Masterton, "The Burning"

[-- Attachment #1.2: dump.1890048.gz --]
[-- Type: application/octet-stream, Size: 179 bytes --]

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: attempt to access beyond end of device

[Piotr Szymaniak]

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

On Mon, Mar 24, 2014 at 11:37:35AM +0400, Vyacheslav Dubeyko wrote:
> Currently, I suspect that you have bad SD card. But, maybe, you have
> something different.

FYI nondestructive read/write badblocks test passed with 0 errors.

Piotr Szymaniak.
-- 
 Relastatyka  czasowa utrzymywała ją w kuli nicości,  której nie należy
mylić z próżnią.  Kula składała się z absolutnej nicości,  w jakiej nie
mogłaby zaistnieć próżnia.
  -- Douglas Adams, "Restaurant at The End of The Universe"

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: attempt to access beyond end of device

[Vyacheslav Dubeyko]

On Mon, 2014-03-24 at 21:49 +0100, Piotr Szymaniak wrote:

> That was some time ago, so I'm unable to answer this question. But
> nilfs-tune shows 4KB blocks:
> 
> ~ # nilfs-tune -l /dev/sdf3
> nilfs-tune 2.1.6
> Filesystem volume name:   (none)
> Filesystem UUID:          53760664-f9ed-4c8d-af42-c6ee2f16d956
> Filesystem magic number:  0x3434
> Filesystem revision #:    2.0
> Filesystem features:      (none)
> Filesystem state:         invalid or mounted,error
> Filesystem OS type:       Linux
> Block size:               4096
> Filesystem created:       Fri Aug  3 08:37:06 2012

I suspect that you used this NILFS2 volume with kernel version that it
was trouble with segments creation. So, you can have volume corruption
because of this bug that it was fixed.

(1) What Linux kernel version do use currently?
(2) How long did you use old kernel versions?
(3) What workloads did you use for this volume?
(4) Had you situations of simultaneous working of several threads with
intensive operations with volume (for example, simultaneous compilation
and checking for updates)?

Thanks,
Vyacheslav Dubeyko.


--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: attempt to access beyond end of device

[Piotr Szymaniak]

[-- Attachment #1: Type: text/plain, Size: 1883 bytes --]

On Tue, Mar 25, 2014 at 01:18:10PM +0400, Vyacheslav Dubeyko wrote:
> On Mon, 2014-03-24 at 21:49 +0100, Piotr Szymaniak wrote:
> 
> > That was some time ago, so I'm unable to answer this question. But
> > nilfs-tune shows 4KB blocks:
> > 
> > ~ # nilfs-tune -l /dev/sdf3
> > nilfs-tune 2.1.6
> > Filesystem volume name:   (none)
> > Filesystem UUID:          53760664-f9ed-4c8d-af42-c6ee2f16d956
> > Filesystem magic number:  0x3434
> > Filesystem revision #:    2.0
> > Filesystem features:      (none)
> > Filesystem state:         invalid or mounted,error
> > Filesystem OS type:       Linux
> > Block size:               4096
> > Filesystem created:       Fri Aug  3 08:37:06 2012
> 
> I suspect that you used this NILFS2 volume with kernel version that it
> was trouble with segments creation. So, you can have volume corruption
> because of this bug that it was fixed.
> 
> (1) What Linux kernel version do use currently?

I think it was 3.6.y or 3.10.y


> (2) How long did you use old kernel versions?

I suppose at least since 2012-10.08 [1] as this is the same Raspberry Pi
and, afair, the same fs. So it was 3.2.27 and then some of (some of them
was unstable) 3.{6,10,11}.y


> (3) What workloads did you use for this volume?

It was almost idle except once a day or two accepting backup from
another machine (but that was kept on external drive/fs).


> (4) Had you situations of simultaneous working of several threads with
> intensive operations with volume (for example, simultaneous compilation
> and checking for updates)?

Could be, but compilation was made on external drive. nilfs holds the
rootfs and almost nothing more.


[1] http://marc.info/?l=linux-nilfs&m=134973563927736&w=2


Piotr Szymaniak.
-- 
Czekajcie,  czekajcie.  Ktos cos do mnie mowil,  ale nie wiem kto i nie
wiem co.
  -- Rafal Solecki

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: attempt to access beyond end of device

[Vyacheslav Dubeyko]

On Thu, 2014-03-27 at 13:39 +0100, Piotr Szymaniak wrote:

> [ 1109.889697] mmcblk0: mmc0:b368 SMI   7.51 GiB 
> [ 1109.891261]  mmcblk0: p1 p2 p3
> [ 1129.467450] NILFS warning: mounting unchecked fs
> [ 1129.956859] NILFS: recovery complete.
> [ 1129.960064] segctord starting. Construction interval = 300 seconds, CP frequency < 30 seconds
> [ 1129.979344] NILFS warning: mounting fs with errors
> [ 1283.005874] attempt to access beyond end of device
> [ 1283.005882] mmcblk0p3: rw=8192, want=145241775180196072, limit=15120384

> > ~ # nilfs-tune -l /dev/sdf3
> > > nilfs-tune 2.1.6
> > > Filesystem volume name:   (none)
> > > Filesystem UUID:          53760664-f9ed-4c8d-af42-c6ee2f16d956
> > > Filesystem magic number:  0x3434
> > > Filesystem revision #:    2.0
> > > Filesystem features:      (none)
> > > Filesystem state:         invalid or mounted,error
> > > Filesystem OS type:       Linux
> > > Block size:               4096

I suppose that you have corrupted file system. Because it is possible to
see that file system has 4 KB block size but the read request is 8 KB in
size (moreover, this request is out of device). You are using this
NILFS2 volume from 2012 year. So, the reason of the issue can be only
corrupted block on the volume.

I assume that there is significant probability of occurrence the issue
with competition of segments for dirty blocks during segment
construction. I've reproduced this issue very stably when it takes place
simultaneous checking for updates and some intensive activity with
volume (for example, compilation). So, such issue results with
corruption of file system. But you can discover such corruption far away
from place of origin.

Anyway, I'll happy to investigate your issue if you can describe a
reproducing path. I need in stable reproducing of the issue for
investigation and fix. Could you describe it?

Thanks,
Vyacheslav Dubeyko.


--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Attempt to Access Beyond End of Device

[Eric Sandeen]

On 04/26/2010 03:20 PM, willis@arlut.utexas.edu wrote:
> Federico Sevilla III wrote: "It wasn't an XFS-centric problem, after
> all"
> 
> Adding Federico's comment... Some Adadptec Controller firmware
> versions will pass incorrect device parameters to the linux kernel.
> The kernel log output misled me to believe is was a corrupt
> filesystem or partition map, however it was just an adaptec bug.
> 
> Adaptac has a fix procedure for this at:
> http://ask.adaptec.com/scripts/adaptec_tic.cfg/php.exe/enduser/std_adp.php?p_faqid=16914

Thanks for the followup; we've seen this a couple times, and it
has always stumped me.

-Eric

>  Below is the my kernel's dmesg output. After following Adaptec's
> procedure, the errors went away and I was able to mount the
> filesystem and see all of my existing data. ----- mount: /dev/sda:
> can't read superblock Mount Error at /dev/sdj. Is filesystem
> realtime? Need a File System? attempt to access beyond end of device 
> sda: rw=0, want=YYYY, limit=XXXX I/O error in filesystem ("sda")
> meta-data dev sdj block 0xZZZZ ("xfs_read_buf") error 5 buf count
> 512 XFS: size check 2 failed -----
> 
> Regards,
> 
> Michael Willis
> 
> 
> 
> 
> 
> -- Eric Sandeen wrote : Federico Sevilla III wrote:
>> Hi,
>> 
>> We've set up Debian GNU/Linux 4.0 "Etch" on an IBM x3400 machine
>> with two 73.4GB SAS hard drives in hardware RAID 1 with a
>> battery-backed cache. We are using the stock Debian 2.6.18-4-686
>> kernel.
> 
> can you send along the results of:
> 
> # xfs_db -r -c "sb 0" -c "print" /dev/sda8?
> 
> and # cat /proc/partitions
> 
> ... and does the hardware raid have a funky sector size?
> 
> -Eric
> 
> 
> 
> -- This message was sent on behalf of willis@arlut.utexas.edu at
> openSubscriber.com 
> http://www.opensubscriber.com/message/linux-xfs@oss.sgi.com/7550412.html
>
>  _______________________________________________ xfs mailing list 
> xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Attempt to Access Beyond End of Device

[Federico Sevilla III]

Hi,

Quoting Bhagi rathi <jahnu77@gmail.com>:
>  I hope your problem with xfs_repair is resolved.

It wasn't an XFS-centric problem, after all. Running cfdisk on the  
system would likewise fail because the partition had been set beyond  
the disk boundary. I'm not sure about how this happened. Either the  
controller reported a large size to Debian during installation, or  
Debian mis-read the reported size on installation. At any rate,  
redoing the entire installation (including RAID setup) with the same  
procedure resulted in the correct (ie: smaller) disk boundaries, so  
the server is back up with the new size.

> Please set your incore log buffer size as a sub-multiple of your log size,
> log size % in core buffer size should be zero (modulo is the operator). This
> is advisable, though not mandatory. Having huge incore buffer size is of no
> help if your on disk log size isn't big. This might solve your problem with
> repair and recovery after some reboots. Make sure that total incore buffer
> size is less than on disk logsize.

Previously, we were using version=1 logs with size=32768b, and then  
mounted using logbufs=8,logbsize=32768.

Now, we are using version=2 logs with size=32768b, and then mounted  
using logbufs=8,logbsize=256k.

If I understand your advise correctly, I should not mount with  
logbsize > 32k, or I should create the filesystem using version=2 logs  
with size=256k. Is this understanding correct?

Are there generic optimization suggestions for I/O-intensive servers  
in general, as far as on-disk and in-memory log buffer sizes are  
concerned?

Please advise.

Thank you very much.

-- 
Federico Sevilla III
F S 3 Consulting Inc.
http://www.fs3.ph

Re: Attempt to Access Beyond End of Device

[Eric Sandeen]

Federico Sevilla III wrote:
> On Mon, 2007-09-10 at 10:47 -0500, Eric Sandeen wrote:
>> can you send along the results of:
>>
>> 	# xfs_db -r -c "sb 0" -c "print" /dev/sda8?
> 
> Will do first thing tomorrow when I get back access to the machine, and
> will revert to the list.
> 
>> and
>> 	# cat /proc/partitions
>>
>> ... and does the hardware raid have a funky sector size?
> 
> Please advise as to how best to usually find this out. 

Dunno :)

FWIW, the size check that is failing is simply looking at the fs
geometry and trying to go out and read the last sector.

-Eric

Re: Attempt to Access Beyond End of Device

[Federico Sevilla III]

[-- Attachment #1: Type: text/plain, Size: 808 bytes --]

On Mon, 2007-09-10 at 10:47 -0500, Eric Sandeen wrote:
> can you send along the results of:
> 
> 	# xfs_db -r -c "sb 0" -c "print" /dev/sda8?

Will do first thing tomorrow when I get back access to the machine, and
will revert to the list.

> and
> 	# cat /proc/partitions
> 
> ... and does the hardware raid have a funky sector size?

Please advise as to how best to usually find this out. For whatever it's
worth, it doesn't allow us to pick a stripe width for RAID 1 (as we
probably shouldn't be able to specify one, anyway). So whatever we're
using is our only choice as far as the hardware RAID 1 goes. (We could
probably use software RAID 1, though, if push comes to shove.)

Thank you very much for your time.

-- 
Federico Sevilla III
F S 3 Consulting Inc.
http://www.fs3.ph

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Attempt to Access Beyond End of Device

[Federico Sevilla III]

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

On Mon, 2007-09-10 at 11:45 -0400, Justin Piszcz wrote:
> Have you checked the following page?
> 
> http://linuxmafia.com/faq/Hardware/sata.html

I checked it now (thanks!) and I believe this is what we've got (or
similar) as we use AACRAID:

        Adaptec AAR 2400, 2410, 2410SA, 2120S, 2200S, 2810SA (8-port),
        21610SA (16-port) series PCI cards — real hardware RAID, using
        the slightly anemic Intel IOP302/303 I/O co-processor chips. Use
        "aacraid" driver. (Should not be confused with the Adaptec 2400A
        ATA RAID host adapter, for which one uses the dpt_i2o driver,
        that card being a legacy of Adaptec's buying DPT — nor with the
        low-end Adaptec AAR 12x0 series, which please see.) Faster at
        random I/O than the 3Ware cards. Optional battery is available
        for the card's cache, for more reliable operation in the event
        of power loss, etc. (Card disables the drive's write cache.)

We also have the optional battery mentioned.

> Does the error occur if you use a different filesystem?

I haven't tried any other filesystem, yet. I'm looking for clues as to
what this could be pointing to, first... and emails like yours are
definitely helping, thank you very much.

Cheers!

-- 
Federico Sevilla III
F S 3 Consulting Inc.
http://www.fs3.ph

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Attempt to Access Beyond End of Device

[Eric Sandeen]

Federico Sevilla III wrote:
> Hi,
> 
> We've set up Debian GNU/Linux 4.0 "Etch" on an IBM x3400 machine with
> two 73.4GB SAS hard drives in hardware RAID 1 with a battery-backed
> cache. We are using the stock Debian 2.6.18-4-686 kernel.

can you send along the results of:

	# xfs_db -r -c "sb 0" -c "print" /dev/sda8?

and
	# cat /proc/partitions

... and does the hardware raid have a funky sector size?

-Eric

Re: Attempt to Access Beyond End of Device

[Justin Piszcz]

On Mon, 10 Sep 2007, Federico Sevilla III wrote:

> On Mon, 2007-09-10 at 10:44 -0400, Justin Piszcz wrote:
>> I believe the logbsize should be in bytes, so 262144, it may also take
>> 256k though I have not tried it.
>
> It accepts 256k. The initial mount succeeded, and the problem did not
> surface until after some reboot (ie: not the first reboot, either, that
> went fine).
>
>> That looks mighty strange, what kind of raid card?
>
> This is the built-in Adaptec AACRAID of the IBM x3400, doing a pretty
> simplistic RAID 1.
>
> -- 
> Federico Sevilla III
> F S 3 Consulting Inc.
> http://www.fs3.ph
>

Have you checked the following page?

http://linuxmafia.com/faq/Hardware/sata.html

Does the error occur if you use a different filesystem?

Justin.

Re: Attempt to Access Beyond End of Device

[Federico Sevilla III]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

On Mon, 2007-09-10 at 10:44 -0400, Justin Piszcz wrote:
> I believe the logbsize should be in bytes, so 262144, it may also take
> 256k though I have not tried it.

It accepts 256k. The initial mount succeeded, and the problem did not
surface until after some reboot (ie: not the first reboot, either, that
went fine).

> That looks mighty strange, what kind of raid card?

This is the built-in Adaptec AACRAID of the IBM x3400, doing a pretty
simplistic RAID 1.

-- 
Federico Sevilla III
F S 3 Consulting Inc.
http://www.fs3.ph

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Attempt to Access Beyond End of Device

[Justin Piszcz]

On Mon, 10 Sep 2007, Federico Sevilla III wrote:

> Hi,
>
> We've set up Debian GNU/Linux 4.0 "Etch" on an IBM x3400 machine with
> two 73.4GB SAS hard drives in hardware RAID 1 with a battery-backed
> cache. We are using the stock Debian 2.6.18-4-686 kernel.
>
> The filesystems were created using the following optimization:
>
>        -l size=32768b,version=2 -n 64k
>
> The filesystems are mounted using the following optimization:
>
>        logbufs=8,logbsize=256k
>
> Today, we were unable to mount the "large" (not really at < 70GB) /var
> (/dev/sda8), getting the following error:
>
>        Attempt to access beyond end of device
>        sda: rw=0, want=143139140, limit=143134720
>        I/O error in filesystem ("sda8") meta-data dev sda8 block
>        0x75cd27f
>        ("xf:read_buf") errors buf count 512
>        XFS: size check 2 failed
>        Mount: /dev/sda8: can't read superblock
>
> An attempted repair also fails:
>
>        # xfs_repair /dev/sda8
>        Phase 1 - find and verify superblock...
>        Attempt to access beyond end of device
>        Sda: rw=0, want=143139140, limit=143134720
>        Xfs_repair: read failed.      Input/output error
>
> The partition table looks okay:
>
>        #Partition table of /dev/sda
>        /dev/sda1 : start=          63,size        9637, Id=83, bootable
>        /dev/sda2 : start=       96390,size   143042760, Id=5
>        /dev/sda3 : start=           0,size           0, Id=0
>        /dev/sda4 : start=           0,size           0, Id=0
>        /dev/sda5 : start=       96453,size     3903732, Id=82
>        /dev/sda6 : start=     4000248,size     7807527, Id=83
>        /dev/sda7 : start=    11807838,size     7807527, Id=83
>        /dev/sda8 : start=    19615428,size   123523722, Id=83
>
> The machine doesn't have valuable data, yet, so a simple reinstall
> should help get it back up. However I'm more concerned about what could
> cause this. It's the first time for me to use a version 2 log, 64k
> directories (?) and 256k in-memory log buffers. Are any of these to
> blame?
>
> We're also looking for generic filesystem tweaks for a PostgreSQL +
> Apache server, which this will be (with more load direct to PostgreSQL
> than to/through Apache). Are the above choices for mkfs.xfs and mount
> well-made?
>
> Please advise.
>
> Thank you very much.
>
> -- 
> Federico Sevilla III
> F S 3 Consulting Inc.
> http://www.fs3.ph
>

I believe the logbsize should be in bytes, so 262144, it may also take
256k though I have not tried it.

As far as the creation, that's a good question, I use SW raid so XFS
auto-tunes it for my hardware.

That looks mighty strange, what kind of raid card?

Justin.

Attempt to Access Beyond End of Device

[Federico Sevilla III]

[-- Attachment #1: Type: text/plain, Size: 2349 bytes --]

Hi,

We've set up Debian GNU/Linux 4.0 "Etch" on an IBM x3400 machine with
two 73.4GB SAS hard drives in hardware RAID 1 with a battery-backed
cache. We are using the stock Debian 2.6.18-4-686 kernel.

The filesystems were created using the following optimization:

        -l size=32768b,version=2 -n 64k

The filesystems are mounted using the following optimization:

        logbufs=8,logbsize=256k

Today, we were unable to mount the "large" (not really at < 70GB) /var
(/dev/sda8), getting the following error:

        Attempt to access beyond end of device
        sda: rw=0, want=143139140, limit=143134720
        I/O error in filesystem ("sda8") meta-data dev sda8 block
        0x75cd27f
        ("xf:read_buf") errors buf count 512
        XFS: size check 2 failed
        Mount: /dev/sda8: can't read superblock

An attempted repair also fails:

        # xfs_repair /dev/sda8
        Phase 1 - find and verify superblock...
        Attempt to access beyond end of device
        Sda: rw=0, want=143139140, limit=143134720
        Xfs_repair: read failed.      Input/output error

The partition table looks okay:

        #Partition table of /dev/sda
        /dev/sda1 : start=          63,size        9637, Id=83, bootable
        /dev/sda2 : start=       96390,size   143042760, Id=5
        /dev/sda3 : start=           0,size           0, Id=0
        /dev/sda4 : start=           0,size           0, Id=0   
        /dev/sda5 : start=       96453,size     3903732, Id=82
        /dev/sda6 : start=     4000248,size     7807527, Id=83
        /dev/sda7 : start=    11807838,size     7807527, Id=83
        /dev/sda8 : start=    19615428,size   123523722, Id=83

The machine doesn't have valuable data, yet, so a simple reinstall
should help get it back up. However I'm more concerned about what could
cause this. It's the first time for me to use a version 2 log, 64k
directories (?) and 256k in-memory log buffers. Are any of these to
blame?

We're also looking for generic filesystem tweaks for a PostgreSQL +
Apache server, which this will be (with more load direct to PostgreSQL
than to/through Apache). Are the above choices for mkfs.xfs and mount
well-made?

Please advise.

Thank you very much.

-- 
Federico Sevilla III
F S 3 Consulting Inc.
http://www.fs3.ph

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

attempt to access beyond end of device

[Koen Vereeken]

I run xen-2.0.5c-4 and kernel-xen-2.6.11.4-20a
and when executing an rsync in my xen instance, i get the following
errors in my /var/log/messages file on domain0 (see snip).
I noticed some other users had this error also in xen2.
Have you tried upgrading to xen3?
If it's fixed in xen3 I will skip further analysis of the problem..

Sep 13 00:38:25 linux kernel: attempt to access beyond end of device
Sep 13 00:38:25 linux kernel: 03:02: rw=0, want=1036632448, limit=10485760
Sep 13 00:38:25 linux kernel: attempt to access beyond end of device
Sep 13 00:38:25 linux kernel: 03:02: rw=0, want=1305318800, limit=10485760
Sep 13 00:38:25 linux kernel: attempt to access beyond end of device
Sep 13 00:38:25 linux kernel: 03:02: rw=0, want=633979264, limit=10485760
Sep 13 00:38:25 linux kernel: attempt to access beyond end of device
...
Sep 13 00:38:26 linux kernel: 03:02: rw=0, want=1372947616, limit=10485760
Sep 13 00:38:26 linux kernel: attempt to access beyond end of device
Sep 13 00:38:26 linux kernel: 03:02: rw=0, want=1036632448, limit=10485760
Sep 13 00:39:51 linux kernel: EXT3-fs warning (device hd(3,2)): empty_dir: bad
directory (dir #1228901) - no data block
Sep 13 00:39:51 linux kernel: EXT3-fs warning (device hd(3,2)): ext3_rmdir:
empty directory has nlink!=2 (0)

attempt to access beyond end of device

[PFC]

	OK, I was a bit stupid...

	I changed a drive today, so I rebuilt a software RAID1.
	I have a RAID1 in degraded mode (1 out of 2 drives), and I added a new  
partition to it. When I say I was stupid, I mean the partition I added was  
a tiny little bit smaller than what it should have been.

	md happily added it, synced, then at the very end :

Jan 19 21:33:27 apollo13 attempt to access beyond end of device
Jan 19 21:33:27 apollo13 sda7: rw=1, want=12498560, limit=12498507
Jan 19 21:33:27 apollo13 raid1: Disk failure on sda7, disabling device.
Jan 19 21:33:27 apollo13        Operation continuing on 1 devices

	Of course, "attempt to access beyond end of device", I made the device  
too small. Duh.

	No problem, I'll just fix my partition, but a warning message on the  
mdadm --add would have avoided losing time doing the sync, and at the end,  
a few seconds of "WTF ? it failed ? ah, ok..."

	Have a nice day !


mdadm --version
mdadm - v2.1 - 12 September 2005

Re: attempt to access beyond end of device

[Luca Ferrari]

On Tuesday 13 April 2004 14:44 Thomas Steudten's cat walking on the keyboard  
wrote:

> Humm, is it possible, that the device was a floppy?
> ls -l /dev/fd0* or cat /proc/devices show you, that
> the block device 2:0 is the floppy device.
> Check this first.

Maybe you're right! I've found that /dev/fd0 was mounted, now I unmounted it 
and I will check the logs.
Thanks,
Luca


-- 
Luca Ferrari,
fluca1978@virgilio.it

Re: attempt to access beyond end of device

[Thomas Steudten]

Humm, is it possible, that the device was a floppy?
ls -l /dev/fd0* or cat /proc/devices show you, that
the block device 2:0 is the floppy device.
Check this first.
>>Try fsck.ext2 (or fsck) with -fvn <your root device eg /dev/hda1>.
>>-n tests in read-only mode.
>>
> 
> 
> Ok, here there's the result:
> 
> fsck 1.27 (8-Mar-2002)
> e2fsck 1.27 (8-Mar-2002)
> Warning!  /dev/hda1 is mounted.
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> 
>       30 inodes used (1%)
>        1 non-contiguous inodes (3.3%)
>          # of inodes with ind/dind/tind blocks: 10/6/0
>     6937 blocks used (86%)
>        0 bad blocks
>        0 large files
> 
>       18 regular files
>        2 directories
>        0 character device files
>        0 block device files
>        0 fifos
>        0 links
>        1 symbolic links (1 fast symbolic links)
>        0 sockets
> --------
>       21 files
> 
> it seems correct, isn't it? I've tried also to dd to /dev/null and it worked 
> well:
> 16002+0 records in
> 16002+0 records out
> 8193024 bytes transferred in 0.454885 seconds (18011202 bytes/sec)
> 
> any idea?
> Thanks,
> Luca
> 
> 
> 

-- 
Tom

LINUX user since kernel 0.99.x 1994.
RPM Alpha packages at http://alpha.steudten.com/packages
Want to know what S.u.S.E 1995 cdrom-set contains?

Re: attempt to access beyond end of device

[Luca Ferrari]

On Tuesday 13 April 2004 13:20 Thomas Steudten's cat walking on the keyboard  
wrote:

> Try fsck.ext2 (or fsck) with -fvn <your root device eg /dev/hda1>.
> -n tests in read-only mode.
>

Ok, here there's the result:

fsck 1.27 (8-Mar-2002)
e2fsck 1.27 (8-Mar-2002)
Warning!  /dev/hda1 is mounted.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

      30 inodes used (1%)
       1 non-contiguous inodes (3.3%)
         # of inodes with ind/dind/tind blocks: 10/6/0
    6937 blocks used (86%)
       0 bad blocks
       0 large files

      18 regular files
       2 directories
       0 character device files
       0 block device files
       0 fifos
       0 links
       1 symbolic links (1 fast symbolic links)
       0 sockets
--------
      21 files

it seems correct, isn't it? I've tried also to dd to /dev/null and it worked 
well:
16002+0 records in
16002+0 records out
8193024 bytes transferred in 0.454885 seconds (18011202 bytes/sec)

any idea?
Thanks,
Luca



-- 
Luca Ferrari,
fluca1978@virgilio.it

Re: attempt to access beyond end of device

[Thomas Steudten]

Try fsck.ext2 (or fsck) with -fvn <your root device eg /dev/hda1>.
-n tests in read-only mode.
> It is a IDE disk, without software raid, formatted as ext2. Since it is the / 
> partition I cannot run fsck immediately to tell you what says, I need to stop 
> the machine.


-- 
Tom

LINUX user since kernel 0.99.x 1994.
RPM Alpha packages at http://alpha.steudten.com/packages
Want to know what S.u.S.E 1995 cdrom-set contains?

Re: attempt to access beyond end of device

[Luca Ferrari]

On Tuesday 13 April 2004 12:41 Thomas Steudten's cat walking on the keyboard  
wrote:

> Luca
>
> Which type of disk? Raid? Which filesystem? What says a file system check
> (fsck)?
> Can you do a dd if=<your partition> of=/dev/null with the same log?
> If not, looks like the filesystem is bad.
>

It is a IDE disk, without software raid, formatted as ext2. Since it is the / 
partition I cannot run fsck immediately to tell you what says, I need to stop 
the machine.

Luca


-- 
Luca Ferrari,
fluca1978@virgilio.it

Re: attempt to access beyond end of device

[Thomas Steudten]

Luca

Which type of disk? Raid? Which filesystem? What says a file system check
(fsck)?
Can you do a dd if=<your partition> of=/dev/null with the same log?
If not, looks like the filesystem is bad.
> since a couple of days I've got these messages in my logs, is a physical 
> problem with the disk?
> 
> Apr 13 06:25:12 linux2 kernel: Directory sread (sector 0x20) failed
> Apr 13 06:25:12 linux2 kernel: attempt to access beyond end of device
> Apr 13 06:25:12 linux2 kernel: 02:00: rw=0, want=16, limit=4

-- 
Tom

LINUX user since kernel 0.99.x 1994.
RPM Alpha packages at http://alpha.steudten.com/packages
Want to know what S.u.S.E 1995 cdrom-set contains?

attempt to access beyond end of device

[Luca Ferrari]

Hi,
since a couple of days I've got these messages in my logs, is a physical 
problem with the disk?

Apr 13 06:25:12 linux2 kernel: Directory sread (sector 0x20) failed
Apr 13 06:25:12 linux2 kernel: attempt to access beyond end of device
Apr 13 06:25:12 linux2 kernel: 02:00: rw=0, want=16, limit=4


Thanks,
Luca

-- 
Luca Ferrari,
fluca1978@virgilio.it

Re: attempt to access beyond end of device

[Justin Pryzby]

Before anyone asks, no my disk is not full:

pryzbyj@perseus:/usr/src/penguin$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda1             3.7G  1.1G  2.5G  31% /
/dev/hda3              19G  349M   18G   2% /home
/dev/hda4              14G  1.5G   12G  12% /usr/src

Sizes shouldn't have changed by more than 01% since I got the error.
Interesting: rerunning `updatedb --localuser=nobody 2>/dev/null` fails to
reproduce the error.

Is the error possibly the result of filesystem corruption?  I imagine that
each directory has a pointer to the disk location of each of its member
files; if that pointer were larger than the disk size, would this error
be the result?

If this is the result of filesystem corruption, it is not necessarily a
problem with ext3 or some othersuch, as I have done some *hard* shutdowns
recently (read: control-alt-backspace on a sis motherboard).

Justin

attempt to access beyond end of device

[Justin Pryzby]

2.4.20-ac1, Debian testing.

While running `updatedb --localuser=nobody 2>/dev/null`, I receive several pages of the following message:

Dec  5 13:43:25 perseus kernel: Directory sread (sector 0x18) failed
Dec  5 13:43:25 perseus kernel: attempt to access beyond end of device
Dec  5 13:43:25 perseus kernel: 02:00: rw=0, want=12, limit=4

Some of the numbers are different sometimes.  I can post my syslog if anyone is interested, but I'm not even sure if this is a kernel issue.

Disk configuration is as follows:

pryzbyj@perseus:~$ mount
/dev/hda1 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw)
/dev/hda3 on /home type ext3 (rw)
/dev/hda4 on /usr/src type ext3 (rw)

Justin

Re: attempt to access beyond end of device

[John Kennedy]

On Thu, Dec 07, 2000 at 05:34:28PM +0100, Andries Brouwer wrote:
> On Thu, Dec 07, 2000 at 04:56:59PM +0100, Jan Niehusmann wrote:
> > That means that if blk_size[major][MINOR(bh->b_rdev)] == 0, the request
> > is canceled but no message is printed. Shouldn't there be a warning message?
> 
> Maybe that code fragment is mine. If so, then at some point
> in time I decided that the answer to your question is no.

  As a potential real-world case (but possibly unrelated), I had an
interesting situation crop-up while I was playing with the loopback
filesystems.

  If you just use the program-tools, you end up with a situation like:

	losetup <blah> [close all] dd <blah> [close all] losetup -d [blah]

  In my case, I was making a standalone program that did it all in one
program and I messed up in the ordering of the close() and the LOOP_CLR_FD.

  I'm pretty sure that (with my small 10K test dataset) the I/O between
the loopback device and the looped file was never hitting the disk.
If I LOOP_CLR_FD before I closed, I ended up with bad data in the looped
file and kernel errors syslogged:

	kernel: attempt to access beyond end of device
	kernel: 07:00: rw=1, want=1, limit=0
	kernel: dev 07:00 blksize=0 blocknr=0 sector=0 size=1024 count=1

  I tended to get 10 of those, one for each of the 10 1K blocks in
my test dataset.

  Doing the close() then the LOOP_CLR_FD got rid of the errors.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: attempt to access beyond end of device

[Andries Brouwer]

On Thu, Dec 07, 2000 at 04:56:59PM +0100, Jan Niehusmann wrote:
> ll_rw_blk.c: generic_make_request() contains the following code:
> 
> if (maxsector < count || maxsector - count < sector) {
> 	bh->b_state &= (1 << BH_Lock) | (1 << BH_Mapped);
> 	if (blk_size[major][MINOR(bh->b_rdev)]) {
> 
> 		/* This may well happen - the kernel calls bread()
> 		   without checking the size of the device, e.g.,
> 		   when mounting a device. */
> 		printk(KERN_INFO
> 		       "attempt to access beyond end of device\n");
> 		printk(KERN_INFO "%s: rw=%d, want=%d, limit=%d\n",
> 		       kdevname(bh->b_rdev), rw,
> 		       (sector + count)>>1,
> 		       blk_size[major][MINOR(bh->b_rdev)]);
> 	}
> 	bh->b_end_io(bh, 0);
> 	return;
> }
> 
> 
> That means that if blk_size[major][MINOR(bh->b_rdev)] == 0, the request
> is canceled but no message is printed. Shouldn't there be a warning message?

Maybe that code fragment is mine. If so, then at some point
in time I decided that the answer to your question is no.

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

attempt to access beyond end of device

[Jan Niehusmann]

ll_rw_blk.c: generic_make_request() contains the following code:

if (maxsector < count || maxsector - count < sector) {
	bh->b_state &= (1 << BH_Lock) | (1 << BH_Mapped);
	if (blk_size[major][MINOR(bh->b_rdev)]) {

		/* This may well happen - the kernel calls bread()
		   without checking the size of the device, e.g.,
		   when mounting a device. */
		printk(KERN_INFO
		       "attempt to access beyond end of device\n");
		printk(KERN_INFO "%s: rw=%d, want=%d, limit=%d\n",
		       kdevname(bh->b_rdev), rw,
		       (sector + count)>>1,
		       blk_size[major][MINOR(bh->b_rdev)]);
	}
	bh->b_end_io(bh, 0);
	return;
}


That means that if blk_size[major][MINOR(bh->b_rdev)] == 0, the request
is canceled but no message is printed. Shouldn't there be a warning message?

Jan





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

attempt to access beyond end of device

[Janek]

Hi,

I have dual P III 665 with 512 MB ram and IBM ServeRAID controller.
It has been running for 40 days without problems but yesterday during
system backup it gave me the following error to syslog:

kernel: attempt to access beyond end of device
kernel: 08:03: rw=0, want=631625768, limit=7912989
kernel: dev 08:03 blksize=4096 blocknr=1768519177 sector=1263251528 size=4096 count=1

with different want numbers.
After a while thise lines changed to :

kernel: EXT2-fs error (device sd(8,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1869575229, count = 1

After backup nothing else was printed. Machine did not crash or anything.
Only MySQL server hanged...

Is this serious ? What chould I do ?

Also I'm using RedHat 6.2 with kernel 2.2.16. MySQL 3.22.32


Thanks,
Janek Hiis


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/