On Sat, Apr 02, 2011 at 01:45:36PM -0500, Amit Kulkarni wrote:
Hi,
I am replying in a single email.
I do a fsck once in a while, not regular. In the last 6-8 months I
might have done it about 5 times. And I did it multi-user the few
times I did it, but plan on doing it single user in
Now, consider this: the fs code is very heavily tested. People use it 24 hours
a day, 365 days a year.
Except on leap years, of course. Those years see even more real-life
testing happening!
On Sun, Apr 10, 2011 at 11:27:41AM +, Miod Vallat wrote:
Now, consider this: the fs code is very heavily tested. People use it 24
hours
a day, 365 days a year.
Except on leap years, of course. Those years see even more real-life
testing happening!
Good point. Maybe we should go to
On Sun, 10 Apr 2011, Marc Espie wrote:
This is completely stupid.
What do you trust more ? your file system, or fsck ?
oth have bugs ! I'm sure of it !
so, if you run fsck, it's likely
you're going to run into fsck bugs eventually (and trying fsck on a mounted
partition was really, really
On Sun, Apr 10, 2011 at 02:40:09PM +0200, David Vasek wrote:
On Sun, 10 Apr 2011, Marc Espie wrote:
This is completely stupid.
What do you trust more ? your file system, or fsck ?
oth have bugs ! I'm sure of it !
so, if you run fsck, it's likely
you're going to run into fsck bugs
On Tue, Apr 5, 2011 at 7:06 AM, Janne Johansson icepic...@gmail.com wrote:
/forcefsck and /fastboot have nothing to do with that
they are not even administered by the fs
I wasn't trying to imply the filesystem is putting the files there, nor
reading them. Rather, those two files show that
On Saturday, April 2, Amit Kulkarni wrote:
FreeBSD which is the origin of FFS does a
background fsck, and if Kirk McCusick feels so strongly I will do it
too.
FreeBSD was not the origin of the FFS code. Background fsck in freebsd
is mainly meant to reduce the amount of time it takes to get
2011/4/2 Benny Lofgren bl-li...@lofgren.biz
I've noticed that some (all?) linux systems do uncalled-for file system
checks at boot if no check have been made recently, but I've never
understood this practice. It must mean they don't trust their own file
systems,
I'm quite sure this comes
On Sun, Apr 3, 2011 at 4:21 AM, Janne Johansson icepic...@gmail.com wrote:
2011/4/2 Benny Lofgren bl-li...@lofgren.biz
I've noticed that some (all?) linux systems do uncalled-for file system
checks at boot if no check have been made recently, but I've never
understood this practice. It must
On 2011-04-01 21.48, Amit Kulkarni wrote:
And jumping up and down after a first successful test is not a sound
engineering principle either.
[...stuff deleted...]
It turns out that I had extracted into the default firefox download
location (/home/amit/downloads I forgot exactly where) all
On 2011-04-01 19.03, Amit Kulkarni wrote:
Thank you Arthur and the team for a very fast turnaround! Thank you
for reducing the pain. I will schedule a fsck every month or so,
knowing it won't screw up anything and be done really quick.
Why schedule fsck runs at all? The file system code is
Hi,
I am replying in a single email.
I do a fsck once in a while, not regular. In the last 6-8 months I
might have done it about 5 times. And I did it multi-user the few
times I did it, but plan on doing it single user in future and I do
plan to do it monthly. After seeing the messages when you
On 2011/04/02 13:45, Amit Kulkarni wrote:
I do a fsck once in a while, not regular. In the last 6-8 months I
might have done it about 5 times. And I did it multi-user the few
times I did it, but plan on doing it single user in future and I do
plan to do it monthly. After seeing the messages
Op 31 mrt. 2011 om 22:25 heeft Otto Moerbeek o...@drijf.net het volgende
geschreven:
On Thu, Mar 31, 2011 at 10:14:46PM +0200, Otto Moerbeek wrote:
So here's an initial, only lightly tested diff.
Beware, this very well could eat your filesystems.
To note any difference, you should use the
Hi Otto,
fsck -p is not possible to do in multi-user because of
# fsck -p /extra
NO WRITE ACCESS
/dev/rwd0m: UNEXPECTED INCONSISTENCY; RUN fsck_ffs MANUALLY.
I haven't checked but it probably wants to do it single user when all
fs are unmounted. And it would work when fs are unclean shutdown.
fOn Fri, Apr 01, 2011 at 12:03:19PM -0500, Amit Kulkarni wrote:
Hi Otto,
fsck -p is not possible to do in multi-user because of
# fsck -p /extra
NO WRITE ACCESS
/dev/rwd0m: UNEXPECTED INCONSISTENCY; RUN fsck_ffs MANUALLY.
Of course. What's the point of checking a mounted filesystem.
What I don't like is that you never have given details (even when
requested) on your extremely slow original fsck which started this
thread. The last couple of years I tested fsck on many different
setups, but I never saw fsck times of 4 hours and not even finished.
So there's something
On Wed, Mar 30, 2011 at 03:45:02PM -0500, Amit Kulkarni wrote:
Hi,
In fsck_ffs's pass1.c it just takes forever for large sized partitions
and also if you have very high number of files stored on that
partition (used inodes count goes high).
fsck main limitation is in pass1.c.
In
On 2011-03-31, Otto Moerbeek o...@drijf.net wrote:
On Wed, Mar 30, 2011 at 03:45:02PM -0500, Amit Kulkarni wrote:
In fsck_ffs's pass1.c it just takes forever for large sized partitions
and also if you have very high number of files stored on that
partition (used inodes count goes high).
If
On 2011-03-31 11.13, Stuart Henderson wrote:
On 2011-03-31, Otto Moerbeek o...@drijf.net wrote:
On Wed, Mar 30, 2011 at 03:45:02PM -0500, Amit Kulkarni wrote:
In fsck_ffs's pass1.c it just takes forever for large sized partitions
and also if you have very high number of files stored on that
On Thu, Mar 31, 2011 at 09:13:41AM +, Stuart Henderson wrote:
On 2011-03-31, Otto Moerbeek o...@drijf.net wrote:
On Wed, Mar 30, 2011 at 03:45:02PM -0500, Amit Kulkarni wrote:
In fsck_ffs's pass1.c it just takes forever for large sized partitions
and also if you have very high number
On Thu, Mar 31, 2011 at 12:30:29PM +0200, Benny Lofgren wrote:
On 2011-03-31 11.13, Stuart Henderson wrote:
On 2011-03-31, Otto Moerbeek o...@drijf.net wrote:
On Wed, Mar 30, 2011 at 03:45:02PM -0500, Amit Kulkarni wrote:
In fsck_ffs's pass1.c it just takes forever for large sized
On 2011/03/31 12:46, Otto Moerbeek wrote:
In general, the default values and algorithms for allocations could
probably do with a tune-up, since of course today's disks are several
magnitudes larger than only a few years ago (let alone than those that
were around when the bulk of the
On Thu, Mar 31, 2011 at 12:30:29PM +0200, Benny Lofgren wrote:
For example, this is what one of my file systems looks like right now:
skynet:~# df -ih /u0
Filesystem SizeUsed Avail Capacity iused ifree %iused
Mounted on
/dev/raid1a 12.6T7.0T5.5T56% 881220
On Thu, Mar 31, 2011 at 09:13:41AM +, Stuart Henderson wrote:
On 2011-03-31, Otto Moerbeek o...@drijf.net wrote:
On Wed, Mar 30, 2011 at 03:45:02PM -0500, Amit Kulkarni wrote:
In fsck_ffs's pass1.c it just takes forever for large sized partitions
and also if you have very high number of
On Thu, Mar 31, 2011 at 02:50:36PM -0500, Amit Kulkarni wrote:
If you really have a lot of used inodes, skipping the unused ones
isn't going to help :-)
You could always build your large-sized filesystems with a larger
value of bytes-per-inode. newfs -i 32768 or 65536 is good for
So here's an initial, only lightly tested diff.
Beware, this very well could eat your filesystems.
To note any difference, you should use the -p mode of fsck_ffs (rc
does that) and the fs should have been mounted with softdep.
I have seen very nice speedups already.
-Otto
Index: dir.c
On Thu, Mar 31, 2011 at 10:14:46PM +0200, Otto Moerbeek wrote:
So here's an initial, only lightly tested diff.
Beware, this very well could eat your filesystems.
To note any difference, you should use the -p mode of fsck_ffs (rc
does that) and the fs should have been mounted with softdep.
On Thu, Mar 31, 2011 at 10:12:07PM +0200, Otto Moerbeek wrote:
So, if I read it correctly, setting just the block size higher to say
64Kb does auto tune frag size to 1/8 which is 8Kb (newfs complains
appropriately) but the auto tune inode length to 4 times frag which is
32Kb is not
If you really have a lot of used inodes, skipping the unused ones
isn't going to help :-)
You could always build your large-sized filesystems with a larger
value of bytes-per-inode. newfs -i 32768 or 65536 is good for common
filesystem use patterns with larger partitions (for specialist uses
I dont think we want to change thed default density. Larger
parttitions already gets larger blocks and fragment, and as a
consequence lower number of inodes.
Otto,
In my tests on AMD64, if FFS partition size increases beyond 30GB,
fsck starts taking exponential time even if you have zero
31 matches
Mail list logo
