On Mon, Aug 16, 2010 at 09:01:42PM +0200, Bernhard R. Link wrote:
> * Perry E. Metzger [100816 20:21]:
> > The most reasonable argument against altering such things is that
> > after decades, people are used to the whole /usr thing and the fight
> > to change it isn't worthwhile. That I will agree
On Fri, Nov 26, 2010 at 03:53:27PM +0100, Raphael Hertzog wrote:
> Just to sum up what dpkg --unpack does in 1.15.8.6:
> 1/ set the package status as half-installed/reinst-required
> 2/ extract all the new files as *.dpkg-new
> 3/ for all the unpacked files: fsync(foo.dpkg-new) followed by
>ren
I did some experimenting, and I figured out what was going on. You're
right, (c) doesn't quite work, because delayed allocation meant that
the writeout didn't take place until the fsync() for each file
happened. I didn't see this at first; my apologies.
However, this *does* work:
extract(a)
On Mon, Nov 29, 2010 at 02:58:16PM +, Ian Jackson wrote:
>
> This is the standard way that ordinary files for which reliability was
> important have been updated on Unix for decades. fsync is for files
> which need synchronisation with things external to the computer (or at
> least, external
On Fri, Dec 31, 2010 at 09:51:50AM -0200, Henrique de Moraes Holschuh wrote:
> On Fri, 31 Dec 2010, Olaf van der Spek wrote:
> > Ah, hehe. BTW, care to respond to the mail I send to you?
>
> There is nothing more I can add to this thread. You want O_ATOMIC. It
> cannot be implemented for all use
On Sun, Jan 02, 2011 at 04:14:15PM +0100, Olaf van der Spek wrote:
>
> Last time you ignored my response, but let's try again.
> The implementation would be comparable to using a temp file, so
> there's no need to keep 2 g in memory.
> Write the 2 g to disk, wait one day, append the 1 k, fsync, up
On Sun, Jan 02, 2011 at 03:14:41PM -0200, Henrique de Moraes Holschuh wrote:
>
> 1. Create unlinked file fd (benefits from kernel support, but doesn't
> require it). If a filesystem cannot support this or the boundary conditions
> are unaceptable, fail. Needs to know the destination name to do t
On Mon, Jan 03, 2011 at 09:49:40AM -0200, Henrique de Moraes Holschuh wrote:
>
> > 1) You care about data loss in the case of power failure, but not in
> > the case of hard drive or storage failure, *AND* you are writing tons
> > and tons of tiny 3-4 byte files and so you are worried about
> > per
On Mon, Jan 03, 2011 at 12:26:29PM +0100, Olaf van der Spek wrote:
>
> Given that the issue has come up before so often, I expected there to
> be a FAQ about it.
Your asking the question over (and over... and over...) doesn't make
it an FAQ. :-)
Aside from your asking over and over, it hasn't
On Wed, Jan 05, 2011 at 01:05:03AM +0100, Olaf van der Spek wrote:
>
> Why is it that you ignore all my responses to technical questions you asked?
>
In general, because they are either (a) not well-formed, or (b) you
are asking me to prove a negative. Getting people to believe that you
can't s
On Wed, Jan 05, 2011 at 12:55:22PM +0100, Olaf van der Spek wrote:
> > If you give me a specific approach, I can tell you why it won't work,
> > or why it won't be accepted by the kernel maintainers (for example,
> > because it involves pouring far too much complexity into the kernel).
>
> Let's c
On Wed, Jan 05, 2011 at 09:38:30PM +0100, Olaf van der Spek wrote:
>
> Performance is important, I agree.
> But you're trading performance for safety here.
... but if the safety is not needed, then you're paying for no good
reason. And if performance is needed, then use fsync().
> > OK, what ab
On Wed, Jan 05, 2011 at 10:47:03PM +0100, Olaf van der Spek wrote:
>
> That was about soft updates. I'm not sure this is just as complex.
Then I invite you to implement it, and start discovering all of the
corner cases for yourself. :-) As I predicted, you're not going to
believe me when I tell
On Thu, Jan 06, 2011 at 12:57:07AM +, Ian Jackson wrote:
> Ted Ts'o writes ("Re: Safe File Update (atomic)"):
> > Then I invite you to implement it, and start discovering all of the
> > corner cases for yourself. :-) As I predicted, you're not going to
>
On Wed, Jan 26, 2011 at 06:14:42PM +0100, Olaf van der Spek wrote:
> On Wed, Jan 26, 2011 at 5:36 PM, Hendrik Sattler
> wrote:
> > BTW: KDE4 is a very good example for failure with modern filesystems. I
> > regularly loose configuration files when suspend-to-ram fails even if the
> > configuration
On Fri, Jan 28, 2011 at 07:37:02AM +0100, Olaf van der Spek wrote:
>
> Is there a way to log cases where (potentially) unsafe writes happen?
> Cases like truncation of an existing file, rename on a target that's
> not yet synced, etc.
Not really, because there are plenty of cases where it's perfe
On Mon, May 14, 2012 at 09:51:43PM +0200, Niels Thykier wrote:
>
> Lintian is outdated (#664600) and the fix has been commited to the git
> repository[1]
I saw a bug report requesting that packages that failed the lintian
udeb-uses-non-gzip-data-tarball check should be summarily rejected.
Did thi
On Mon, May 14, 2012 at 10:20:08PM +0200, Philipp Kern wrote:
>
> as soon as we get a hold of an ftp-master the autoreject will be dropped.
> We'll certainly don't wait until Lintian is backported. ;-)
>
Great, thanks for the clarification. I wasn't aware of
http://ftp-master.debian.or
On Fri, May 25, 2012 at 11:11:06AM +0200, Salvo Tomaselli wrote:
> > Files which are written on a regular filesystem stay on memory. This is
> > called the buffer cache. Whenever they are not used and/or the system
> > needs to reclaim memory, they are trashed.
> > Files which are written on a tmpf
On Fri, May 25, 2012 at 02:49:14PM +0100, Will Daniels wrote:
> On 25/05/12 13:52, Ted Ts'o wrote:
> >So what? If you write to a normal file system, it goes into the page
> >cache, which is pretty much the same as writing into tmpfs. In both
> >cases if you have swap
On Sat, May 26, 2012 at 09:29:30PM +0700, Ivan Shmakov wrote:
> … But that makes me recall a solution to both the /tmp and quota
> issues I've seen somewhere: use ~/tmp/ instead of /tmp. This
> way, user's temporary files will be subject to exactly the same
> limits as all
On Thu, Jun 14, 2012 at 09:22:43PM -0700, Russ Allbery wrote:
> "Theodore Ts'o" writes:
>
> > If a required package (such as e2fslibs, which is required by e2fsprogs)
> > provides multiarch support, then Lintian requires that the package have
> > a dependency on the package "multiarch-support"[1]
On Sun, Jul 08, 2012 at 10:00:05AM -0600, Paul Wise wrote:
> On Sun, Jul 8, 2012 at 7:15 AM, Wookey wrote:
> > Will Android machines make secure boot turn-offable or another key
> > installable, or will thay follow the Microsoft lead and lock
> > everything down too?
>
> Are there any Android devi
On Fri, Jul 06, 2012 at 05:32:44AM +0100, Ben Hutchings wrote:
>
> 2. Upstream kernel support: when booted in Secure Boot mode, Linux would
> only load signed kernel modules and disable the various debug interfaces
> that allow code injection. I'm aware that David Howells, Matthew
> Garrett and o
On Mon, Jul 09, 2012 at 04:48:38PM +0100, Matthew Garrett wrote:
> In article <20120708235244.gb24...@thunk.org> Ted Ts'o wrote:
> > Matthew Garret believes that this is a requirement; however, there is
> > no documented paper trail indicating that this is actually nece
On Fri, Dec 16, 2011 at 02:38:11PM +, Lars Wirzenius wrote:
> On Fri, Dec 16, 2011 at 02:13:29PM +0100, Stig Sandbeck Mathisen wrote:
> > Simon McVittie writes:
> >
> > > life's too short to spend time booting in single-user mode and
> > > resizing LVs.
> >
> > That's probably why we now hav
On Wed, Dec 21, 2011 at 02:32:58PM +0100, Goswin von Brederlow wrote:
> > If we want to improve fsck time then the best thing to do would be
> > to consider a different default value for the -i option of mke2fs.
This advice is not applicable for ext4, since it will not read unused
portions of the
On Sat, Mar 26, 2011 at 10:42:09PM +, Mark Hymers wrote:
>
> The only other thing I can see is that e2fsprogs contains lsattr and
> chattr - a quick grep through my local /var/lib/dpkg/info shows that
> chattr is used in the postfix postinst without an explicit dependency.
> I wonder if there
reassign 616317 base
thanks
This isn't a bug in e2fsprogs; e2fsprogs has absolutely nothing to do
with mounting the file system.
Debian simply doesn't support the mount options for the root file
system in /etc/fstab having any effect on how the root file system is
mounted. The root file system i
On Mon, Sep 19, 2011 at 08:51:00AM +0200, Tollef Fog Heen wrote:
> ]] "Theodore Ts'o"
>
> | and that's the correct location of pkgconfig files, which currently are
> | stored at /usr/lib/pkgconfig/.pc. The Wiki page seems to imply
> | the correct location is /usr/lib//pkgconfig/.pc. And
> | I
On Mon, Sep 19, 2011 at 10:00:35PM +0200, Josselin Mouette wrote:
> Le lundi 19 septembre 2011 à 18:56 +0100, Simon McVittie a écrit :
> > > The correct place for debug files is a hash-based path, instead of the
> > > crapfuck we have today.
> >
> > ... but until then, for gdb to pick them up, de
31 matches
Mail list logo
