Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*file\s+corruption\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*file\s+corruption\s*$/: 64 ]

Total 64 documents matching your query.

1. Re: file corruption (score: 1): Author: Chris Wedgwood <cw@xxxxxxxx>; Date: Thu, 1 Apr 2004 16:18:01 -0800; Define corrupted. Random garbage? As someone else pointed out you can get nulls in files at times, but I wouldn't expect it to be that common or problematic -- it's also arguably the correct behavior; /archives/xfs/2004-04/msg00002.html (8,893 bytes)
2. Re: file corruption (score: 1): Author: Dmitry Nikiforov <dniq_kraft@xxxxxxxxxxxxxxx>; Date: Thu, 01 Apr 2004 18:52:43 -0600; 'Corrupted' as in 'incorrect data in them'. Besides, a few files were lost (Mozilla bookmarks.html, for example, is one of them). Well, it looks like a random garbage. Last time it happened to /var/l; /archives/xfs/2004-04/msg00004.html (11,636 bytes)
3. Re: file corruption (score: 1): Author: Chris Wedgwood <cw@xxxxxxxx>; Date: Thu, 1 Apr 2004 17:16:18 -0800; Incorrect data can/will happen for some files. XFS journals metadata not data so this is expected unless applications take sufficient care (MTAs like postfix a good example of applications which do t; /archives/xfs/2004-04/msg00005.html (10,798 bytes)
4. Re: file corruption (score: 1): Author: Dmitry Nikiforov <dniq_kraft@xxxxxxxxxxxxxxx>; Date: Thu, 01 Apr 2004 19:42:48 -0600; So technically the whole purpose of this is to provide faster startup time after crash and not the consistency of data, correct? I'll try to experiment a little bit... I can't tell you right now, sin; /archives/xfs/2004-04/msg00006.html (11,720 bytes)
5. Re: file corruption (score: 1): Author: Chris Wedgwood <cw@xxxxxxxx>; Date: Thu, 1 Apr 2004 17:50:22 -0800; yes some fs' will journal all data though (reiserfs and ext3 can do this), but it often comes at a significant performance penalty for no real gain (and sometimes causes other problems like seeing ol; /archives/xfs/2004-04/msg00007.html (10,119 bytes)
6. Re: file corruption (score: 1): Author: Christian Rice <xian@xxxxxxxxxxx>; Date: Thu, 01 Apr 2004 18:25:12 -0800; Has anyone mentioned turning off write caching? hdparm -W 0 /dev/hda This for me made the difference between rebuilding up to five system disks per day (out of one hundred desktop workstations, and t; /archives/xfs/2004-04/msg00008.html (11,619 bytes)
7. Re: file corruption (score: 1): Author: Dmitry Nikiforov <dniq@xxxxxxxxxxxxxxx>; Date: Thu, 01 Apr 2004 21:05:51 -0600; Then there's no point in using XFS at all, is there? :) -- Regards, DNiq.; /archives/xfs/2004-04/msg00009.html (10,068 bytes)
8. Re: file corruption (score: 1): Author: Ethan Benson <erbenson@xxxxxxxxxx>; Date: Thu, 1 Apr 2004 19:39:20 -0900; I have seen this a few times as well, except the binary crap is usually PREpended rather then appended to the file, also the end of the file is usually cut off, as if the start and end markers were e; /archives/xfs/2004-04/msg00010.html (10,432 bytes)
9. Re: file corruption (score: 1): Author: Chris Wedgwood <cw@xxxxxxxx>; Date: Thu, 1 Apr 2004 20:44:56 -0800; Actually, this is a good point, until XFS gets some write-barrier support this is probably a good idea. Newer drives with 8MB caches are worse... you can get quite a bit of data reordered and/or lost; /archives/xfs/2004-04/msg00011.html (10,479 bytes)
10. Re: file corruption (score: 1): Author: Chris Wedgwood <cw@xxxxxxxx>; Date: Thu, 1 Apr 2004 20:47:12 -0800; This has nothing to do with XFS. All filesystems journalling and otherwise are affected by this. --cw; /archives/xfs/2004-04/msg00012.html (9,769 bytes)
11. Re: file corruption (score: 1): Author: Chris Wedgwood <cw@xxxxxxxx>; Date: Thu, 1 Apr 2004 20:48:27 -0800; How much data are we talking about here? For > blocksize this seems impssible. --cw; /archives/xfs/2004-04/msg00013.html (9,103 bytes)
12. Re: file corruption (score: 1): Author: Dmitry Nikiforov <dniq@xxxxxxxxxxxxxxx>; Date: Fri, 02 Apr 2004 00:40:36 -0600; Agree, but different filesystems are affected to a different degree. So far I've not had any data lost with, say, ext3, however its performance is pretty poor. For now, I've reformatted all partition; /archives/xfs/2004-04/msg00015.html (10,942 bytes)
13. Re: file corruption (score: 1): Author: Ethan Benson <erbenson@xxxxxxxxxx>; Date: Thu, 1 Apr 2004 22:13:49 -0900; no more then 5 - 15 bytes or so. its definitly quite strange, i couldn't really make any guess as to what would cause it. but its definitly possible since ive seen it happen several times on multiple; /archives/xfs/2004-04/msg00016.html (10,594 bytes)
14. Re: file corruption (score: 1): Author: Chris Wedgwood <cw@xxxxxxxx>; Date: Fri, 2 Apr 2004 00:50:20 -0800; Sorry, I meant how large are the files ... not by how much are they shifted. How can you tell if a compressed file is shifted 5-15 bytes? Casual inspection will fail to decompress the data I would ex; /archives/xfs/2004-04/msg00018.html (9,289 bytes)
15. Re: file corruption (score: 1): Author: Chris Wedgwood <cw@xxxxxxxx>; Date: Fri, 2 Apr 2004 00:53:08 -0800; ext2 sounds like a good solution then. You're most welcome. Best of luck with reiserfs. --cw; /archives/xfs/2004-04/msg00019.html (10,595 bytes)
16. Re: file corruption (score: 1): Author: Ethan Benson <erbenson@xxxxxxxxxx>; Date: Fri, 2 Apr 2004 00:28:57 -0900; if your worried about data corruption/loss, reiserfs is the last fs you want to run to... -- Ethan Benson http://www.alaska.net/~erbenson/ -- Attached file included as plaintext by Ecartis -- --BEGIN; /archives/xfs/2004-04/msg00020.html (10,969 bytes)
17. Re: file corruption (score: 1): Author: Ethan Benson <erbenson@xxxxxxxxxx>; Date: Fri, 2 Apr 2004 00:33:54 -0900; ah, various sizes all the apache archived logs were affected (except the most recent version as i recall). they range from 500K to 5MB. the rest of the compressed logs range form a couple K to aboug; /archives/xfs/2004-04/msg00025.html (10,847 bytes)
18. Re: file corruption (score: 1): Author: Leroy van Logchem <leroy.vanlogchem@xxxxxxxxxx>; Date: Fri, 02 Apr 2004 13:23:18 +0200; Just use UFS2 on FreeBSD and be happy ever after. No corruption no loss just production quality. Been there.... never to return again.; /archives/xfs/2004-04/msg00029.html (11,140 bytes)
19. Re: file corruption (score: 1): Author: Chris Wedgwood <cw@xxxxxxxx>; Date: Fri, 2 Apr 2004 10:28:32 -0800; i can't think if anything which would cause entire files to have data shifted, and presumably this is across block boundaries too? without more data this is really hard to comment on; /archives/xfs/2004-04/msg00035.html (9,170 bytes)
20. Re: file corruption (score: 1): Author: Ethan Benson <erbenson@xxxxxxxxxx>; Date: Fri, 2 Apr 2004 19:10:54 -0900; i know.. thats why ive never brought it up before, but the other user's report sounded quite similar to my experience. -- Ethan Benson http://www.alaska.net/~erbenson/ -- Attached file included as pl; /archives/xfs/2004-04/msg00039.html (10,328 bytes)

Current List: 1 - 20
Page: [1] [2] [3] [4]